component:getsource query does not wait for runtime:ports message

[ERnsTL]

During the implementation of a new FBP network-protocol capable runtime (called flowd-rs, see Github, re-implementation of the previous flowd runtime), the following showed up:

Once enabling the capability component:getsource, the error message "Not permitted to send component:getsource messages" disappeared but there seems to be another problem to the error message "Unknown format for Rust graph Repeat" (may be a race condition or the payload attributes have the same names by bad luck):

Position of error message

The specification states there: "If the runtime is currently running a graph and it is able to speak the full Runtime protocol, it should follow up with a ports message."

"It should follow up with a ports message" seems to be interpreted that immediately after the runtime:runtime message, it should send a separate WebSocket message of type runtime:ports.

If this interpretation is correct, then noflo-ui does not wait for the follow-up runtime:ports message but proceeds to query the source code of the graph using a component:getsource message. But component:getsource only applies to components, not graphs?

Then it seems to get worse from there, I have attached the message exchange.

Maybe this is all just because the protocol implementation is being built up step by step

Implementation progression is as follows:

runtime:getruntime -> runtime:runtime + runtime:ports component:list -> component:component + component:componentsready network:getstatus -> network:status

Then noflo-ui complained that it is not allowed to request component:getsource, so I implemented it and allowed the capability.

component:getsource -> component:source

...but then noflo-ui immediately sends component:getsource for the graph name and disregards the follow-up runtime:ports message ... and the above-described error happens.

Without enabling the capability component:getsource, the progression of request messages and responses seems reasonable:

(But it complains about the missing capability component:getsource.) (list of allowed capabilities was protocol:runtime, network:status, protocol:component, graph:readonly in order to get started)

Not sure where the problem is located: My new implementation, the fbp-protocol spec or noflo-ui.

Request for comments on the above, would like to continue with the FBP protocol implementation proper.

[bergie]

Hey, thanks for the bug report! I think we're a little bit under-documented on how the "live mode" when connected to a runtime works.

Here's the basic flow of messaging:

• runtime:getruntime: get the runtime capabilities allowed to the user, as well as the name of the main graph the runtime is running, if any (in your examples, your runtime reports this with name default_graph)
• If the runtime is running a graph, then get the graph sources via component:getsource so it can be rendered and made editable in noflo-ui. For graphs, the assumed language is json and the format should be compatible with this schema
• Get the components list from the runtime via component:list
• Get the sources for all components in the same namespace as the one the runtime reported in runtime:getruntime so we can populate all editable entities of the project

So for full live mode, we need the ability to get/set source. We have to use getsource to fetch graph sources since there is no fbp-protocol method to fetch graphs in another way.

I would admit that this functionality is really poorly tested in noflo-ui when dealing with runtimes that don't provide the full set of capabilities. That's definitely an area of interest.

Let me know if I can help more.

[ERnsTL]

Thanks Henri for the quick reply!

It makes sense now, will continue with the implementation in this way. Hopefully I can report back with a runtime in Rust.

Another thing popped up, what is the difference between "started" and "running", for example in the network:status message?

Maybe this is because of fine differences in language/word meaning, but right now I am not sure.

The other messages look clear so far.

[bergie]

• started: has the network been started
• running: is the network running at the moment

So: started: true, running: true means network is now running, started: true, running: false means network has finished, started: false, running: false means network was never started.

I think would be better to handle these in the fbp-protocol repo so the corner cases are more discoverable. I'll close this ticket here.