Feature: Support Recv option to requeue a failed match message
- Dominant language
- Go
- Stars
- 8
- Forks
- 13
- PR merge metrics
- No merged PRs in 30d
Description
Say you want to `recv` two messages without respect to order. For example, you want to `recv` `"queso"` and also `recv` `"nachos"`, but you don't know the order that those messages will arrive (and you don't care). Currently you might have to resort to using a guard and perhaps additional state, and that work is tedious.
Instead, `recv` could maybe support a `requeueonfail` option, which would queue a message that failed a match so that the message could be re-received later. Example use:
```yaml
spec:
phases:
phase1:
steps:
- '$include'
- run: |
// A hack to randomize the order in which we say and hear
// things.
var t = now(),
n = t[t.length - 5]; // A digit from nanoseconds.
flip = n % 2 == 0;
test.Bindings["?first"] = flip ? "nachos": "queso";
test.Bindings["?second"] = !flip ? "nachos": "queso";
- ingest:
doc: |
Send a message to ourselves. Use our randomly-chosen
"first" value.
payload: '{"want":"?first"}'
- ingest:
doc: |
Send another message to ourselves. Use the other value.
payload: '{"want":"?second"}'
- recv:
pattern: '{"want":"queso"}'
requeueonfail: true
- recv:
pattern: '{"want":"nachos"}'
requeueonfail: true
```
In this example, we'll hear `"nachos"` and then `"queso"` or we'll near `"queso"` and then `"nachos"`. We'd like to verify we hear both, but we do not want to specify the order or resort to guards. The `requestonfail` option would tell `recv` to queue a message that fails the match rather than to drop it. That way the second `recv` will see a message that the first `recv` rejected.
It's not hard to imagine this behavior causing a lot of confusion; however, it seems useful in certain narrow circumstances.
Contributor guide
Assessment
This issue has not been assessed yet.