-
Notifications
You must be signed in to change notification settings - Fork 42
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
Fix unresumable Sender #443
Conversation
469052e
to
c0e1d10
Compare
Pull Request Test Coverage Report for Build 12465664083Details
💛 - Coveralls |
c0e1d10
to
5b25a0f
Compare
The Sender was generating new hpke keys on resume since keygen was being done in `extract_v2`. This caused a problem where when the Sender was persisted, stopped, and resumed, the receiver would have already pushed a response to a different ShortId than the one the Sender would look for it in the resumed state. By generating a key on Sender creation and persisting that the Sender can produce a consistent HpkeContext every single run.
c8fd0a3
to
226816a
Compare
It looks like the e2e test is silently swallowing errors somehow. This is in
|
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.
tACK 226816a
I pushed a fix for the e2e test to correctly bubble up payjoin-cli errors, and confirmed that this commit currently fails on |
Bubble up payjoin-cli errors instead of silently swallowing them.
f1dd5af
to
86a9a8a
Compare
Also tested 86a9a8a cherry-picked on top of master to make sure it fails. good catch. |
The Sender was generating new hpke keys on resume since keygen was being done in
extract_v2
. This caused a problem where when the Sender was persisted, stopped, and resumed, the receiver would have already pushed a response to a different ShortId than the one the Sender would look for it in the resumed state.By generating a key on Sender creation and persisting that the Sender can produce a consistent HpkeContext every single run.
I am NOT sure why the e2e test did not catch this. I believed its behavior was starting a receiver, stopping it, starting a sender, stopping it, resuiming a receiver, stopping it, and resuming a sender, and stopping it which is where this bug propagated. It didn't fail before this change and I'm not sure why, it should have.