Feature Request
Closed this issue · 11 comments
Can we put meta info about the queue in the flow context?
ie current state, queue size, max queue length, etc?
I can see why this information could be useful. In fact, that is why it is (mostly) made available in the node status. The status text includes the state (open, closed, or queueing) and, if in the queuing state, the number of messages in the queue. A status node catching that text could easily inject the information into a flow or global variable. If the maximum queue length is really valuable for important use cases it could be added to the status text in a form something like queueing: 3/5, meaning 3 messages in a queue of maximum length 5. (The current output would be queueing: 3.)
There are good reasons not to use flow or global variables for this. First, it would be poor practice to hard-code a variable name, even as a default, since it could conflict with user variables, and the name might be difficult to discover. Adding another user-defined variable name in the node editor just adds complexity. Second, the issue of persistence arises, because a user-defined variable name could be lost on a re-deploy unless special steps were taken.
As I suggested above, the one change that I think might add value would be to include the maximum queue length in the status text. Unfortunately, this would be a breaking change for anyone using that text as part of a flow. Still, if there is a really compelling use case, it might be worthwhile. What do you think?
The user already has a means of knowing the queue length so I think that might argue against the case for adding it to the status, particularly as a breaking change.
@colinl, I tend to agree. The important stuff is what changes during operation and is not under the user's direct control.
I'm sorry I didn't make myself clear. Changing the contents of the status text would be a breaking change. Adding flow or global variables is likely to be a non-starter for the reasons I discussed, but I will be happy to look at a PR.
@drmibell I wonder whether your requirement has been misunderstood. Could you explain again exactly what you want to achieve?
Colin, @adamclerk has the requirement, and, yes it might help to have a clearer definition.
@colinl I wanted a sibling node to know how many items are in the queue. So the sibling node can decided either to trigger(until empty) and then open the queue...or just open the queue.
As I think about it more. I'm not sure I'll need it. I think I can create my workflow successfully with just queued and open states.
@adamclerk did you see what @drmibell said about using the status node if you need the number of messages in the queue?
I found the node! I didn't know it could do that. Sorry for taking up your valuable time.