-
Notifications
You must be signed in to change notification settings - Fork 1
reproduce signal delivery ordering misunderstaning #251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
a137ce0 to
2946fc5
Compare
📊 Code Coverage ReportCurrent PR CoverageOverall Coverage: 🟠 57.9%
Overall Summary
Coverage by Module
🟢 ≥80% 🟡 ≥60% 🟠 ≥40% 🔴 <40% 📈 Coverage Comparison vs. Main✅ Coverage increased by .1% (57.8% → 57.9%) Main Branch Coverage (for comparison)Overall Coverage: 🟠 57.8%
Overall Summary
Coverage by Module
🟢 ≥80% 🟡 ≥60% 🟠 ≥40% 🔴 <40% |
sdk/test/IntegrationSpec.hs
Outdated
| signalWithArgs | ||
| 1 | ||
|
|
||
| -- liftIO $ threadDelay 1_000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the test succeeds if this line is uncommented, so it looks like there is some sort of window of time affecting how state var changes get sequenced
| t <- now | ||
| readStateVar var >>= \s -> writeStateVar var (MinPQueue.insert t i s) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the fact that this works implies that things are getting processed in-order, so it looks like statevar operations are messed up.
fwiw i also tried this with modifyStateVar & it reproduced the issue which means it's not a read *> write sequence issue.
description
this reproduces signal delivery ordering behavior we observed in production code, where
signalWithStartfollowed bysignalin short succession does not necessarily guarantee in-order modification ofStateVars.signals are, however, processed in-order: if the signal handler gets the time at which it is processed with
Workflow.nowand uses that as a priority ordering key then things look the way that we expect them to.6c0e06b fails with the same thing we saw in prod:
failure
...but 2946fc5 succeeds when it uses a priority queue to insert according to received timestamp:
success