Right now there is nothing with is very scary. Should just take some input trace files, process/setup using various (high-level) options and verify regular output.

For replay this means the FBP protocol, for show it means the strings outputted.

For instance:

• Only events after / from a particular edge/connection
• Only events before / up-until a particular edge/connection

Should be able to target inside a subgraph, and to combine these to get a particular view.

Right now have to manually copy&paste the url.

https://github.com/sindresorhus/opn

Should allow to disable this behavior --open=false.

Would connect to a runtime over the FBP runtime protocol, and listen there for messages and from those produce a flowtrace file.

This allow to listen remotely, for instance if the runtime under investigation does not have capacity/permissions to write a flowtrace to disk. Often it is also more convenient to have the files on a developer machine. And it enables using flowtrace with FBP runtimes which do not have integrated support for flowtrace (but support the protocol).

This is basically the opposite of the already existing flowtrace-replay.

Should be autodeploy via Travis.
Could use Github Pages for hosting, would then appear as https://flowbased.github.com/flowtrace

Combined with #25, #24 and something like noflo/noflo-runtime-base#64 + #2, could be a minimally-useful post-mortem debugger for issues that happens in CI or production.

Would require the trace to either:

• Have code of all components included (very large, and won't work for non-component things included by component)
• Have enough info to know which component versions where, and how to look up the info. For node.js, this could based on a npm list dump, though maybe one should extract repo (typically but not alway github) from the package.json right away. Then would have to get the path from base of repo to the particular component. And have a way to HTTP GET the actual source code..

Since we want this in a non-NPM specific manner in general, there are some relationships here to noflo/noflo#247

Looks like this now when redirecting output to a file...

�[34m�[3m-> CSS image/GetColors_at7fj�[23m�[39m �[33mCONN�[39m
�[34m�[3m-> CSS image/GetColors_at7fj�[23m�[39m �[32mDATA�[39m false
�[34m�[3m-> CSS image/GetColors_at7fj�[23m�[39m �[33mDISC�[39m

Currently hardcoded to localhost

Version 2.16.0 of commander was just published.

This version is covered by your current version range and after updating it in your project the build failed.

commander is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

This way debugging tools can be live updated with changes to the system.

One possibility is to use text/event-stream format. It is a simple \n\n delimited format, with good support for JSON payloads.
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#Event_stream_format
It has the benefit of also being used in server-side-events which is supported by webbrowsers.

The header information like the graph should also be sent as an event. It should be supported to have this change in the middle of a stream also.
Ideally tools can also deal with the header not being present, and recontructing information from data events (to the extent possible)

Just using the code also from the command-line tool for instance.
Especially since the graphical timeline etc is kinda useless right now.

Should also be configurable as a URL parameter (ref #24).

For instance interesting to find which connections have certain data come past. Also what groups it was included with it at that time. Mostly so one can find a particular request, and then do other filtering later.

Should load the trace and display it.

It should be possible to annotate a trace, with comments / metadata. This is especially useful when collaborating, as a developer can add their analysis/questions in a way that other tools can then display.
It may also be useful for semi/automated analysis tools to inject annotations, to point to specific areas of interest.

Annotations should be stored outside the events stream, as an event is considered immutable.
Possibly we should add an 'event id', to allow such references to be done in an unambigious way (even when trace is/has-been transformed). As a prototype one could use the array index though.

Needs to be calculated from timestamp.

Needs to use groups to correlate events I guess?

When we support uploading to a service like Flowhub (#2), flowtrace-replay and flowtrace-show should be able to show information directly from a URL. This likely requires them to pass along authentication information, which should be read from an envvar.

Version 1.0.3 of grunt was just published.

This version is covered by your current version range and after updating it in your project the build failed.

grunt is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Version 1.2.5 of grunt-bower-install-simple was just published.

This version is covered by your current version range and after updating it in your project the build failed.

grunt-bower-install-simple is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

When capturing traces from production environment with lots of processing, one often encounters scenarios where many failures are in fact caused by same bug/issue. And that small changes in inputs often are difference between triggering an issue or not, and that such differences can say a lot about the nature of the bug.

Interesting questions include:

• How many distinct failure classes exists, and how many of each are there
• What are the boundary conditions between fail and success

With the ability to upload traces to a service (#2), it becomes interesting to have cloud-based tools which help answer these problem at scale. Performance of making the needed analysis - both how quick to get results, and how much it costs, are key considerations.

References

• https://en.wikipedia.org/wiki/Cluster_analysis
• http://www.cs.cmu.edu/~ninamf/papers/clustering-bbv-long.pdf

Should be workflow oriented. "this is how you do that"

Version 1.1.0 of grunt-contrib-watch was just published.

This version is covered by your current version range and after updating it in your project the build failed.

grunt-contrib-watch is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Should be transparently handled when loading.

Need to standardize supported compression schemes

Version 5.2.0 of mocha was just published.

This version is covered by your current version range and after updating it in your project the build failed.

mocha is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Useful to be able to debug an issue with different code/environment.
Should be able to specify which edge to inject into, and which to read from (default to same as inject).

Sometimes the issue/bug is caused inside component code, like an exception / returned Error.

In this case it would be nice to be able to look inside the component, and see exception wrt to that. Like a regular imperative/OOP debugger.

Must be able to look up component code, #6

Now the runtime gets a random UUID every time it is started, which is somewhat confusing to clients like noflo-ui. It would be better to generate a UUID and persist it in the pwd in a dotfile.

At least

• Show only events with a particular group
• Show events with no group (major warning for concurrent graphs!)
• (for completeness) Everything not matching a particular group

Should be possible to add multiple such matching rules.

Later we'd probably also want:

• Maybe want regexp matching for groups
• Matching against a particular level of group

Especially useful for sending traces from automated tests ran on Travis CI, or production systems.

Basically we're reusing a lot of other FBP formats, like the protocol and graph format.

Ideally those would have JSON schemas which we could just refer, but that is currently not in a good shape. Might be good to start with a top-level schema here, where we are starting from scratch and plug in more as we improve the other specs.

Should give machine-readable data, to compliment flowtrace-show (which gives human-friendly output).

Should reuse the filtering options (#10 #11 #12). By default should probably create a new Flowtrace file with "subtrace". But should also have other options to extract other things, for working onwards using other tools.

• Extract a particular graph
• Extract only data on edges
• (for completeness) Extract only groups

Maybe option for

First need to store it, noflo/noflo-runtime-base#32
Then send over FBP protocol as component messages

For many bugs, it is often possible to narrow things down to get one (or more) test run which succeeds, and one (or more) test runs which fails.
Sometimes the cause for difference is in input data, and sometimes in the (version of) code used. Or in some cases, the environment the code is executing in.

But then to figure out why exactly this makes causes difference in behavior. In dataflow/FBP that usually means following the data until it starts diverging. A tricky/tedious part is usually being able to distinguish the insignificant from significant differences.
There might be timestamps, payload sizes etcs that continiously vary, but are not of interest. Or in other cases, there are slight differences which are functionally equivalent. For instance existance or value of some keys in an object might not matter at all. Or addition/removal of some elements of an array (but not others).
In general we'd need tooling that brings down the differences enough to be analyzed/understood easily/quickly by the developer. It should allow to progressively tighten whats shown when one has narrowed down possibilities.

If one does not know if difference is input or code/graphs, it may be useful with tools to help figure that out. For diffing the graphs, some integration with (yet to be developed) fbp-diff may be useful. Alternatively, one could use require user to combine (proposed)[https://github.com/flowbased/flowtrace/issue/13] flowtrace-extract --graph + fbp-spec for that.