Ah yes - that would also do it.
Right. (Also, set the default state as queueing.) I didn't suggest this because I misunderstood the requirement as needing the message passed through as well as retained for later retrieval. Used in parallel with whatever path processes the message, this configuration should be fine as a poll-able store or store-and-forward node. Something that might be worth adding would be an easy way to distinguish a retrieved message from the original one or retrieved messages from one another.
Maybe the retrieved message could have the peek property attached?
Exactly. Possibly also an index number (how many copies have been sent). Just one more thing to save in node context, but not a big deal. I wonder whether this is a significant enough use case to be worth the effort, including documentation, example(?), etc.
Why add the count ? Has anyone asked for it ?
I meant a property attached to each retrieval, distinguishing one from another, possibly to help keep track of their processing. Has anyone really asked for anything beyond what @Colin suggested? I'll be happy to respond to an issue on GitHub...
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
