-
Notifications
You must be signed in to change notification settings - Fork 2.7k
feat(coprocessor): implement a retry mechanism for pbs computations #1245
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
4dd0220 to
b33d326
Compare
rudy-6-4
left a comment
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.
Can a small test be added ? Otherwise a e2e run in PR comment gives more confidence to reviewer.
We'll probably need to mock the squash_noise call to simulate erroneous behavior and also enforce a DB insert-query failure but that's not trivial. Let me think about it. |
b0f0036 to
5e9ea06
Compare
PBS computation can be in one of the following states: - completed - squash_noise finished and the ct128 was inserted into the DB - TransientErr - squash_noise finished but the ct128 couldn't be inserted - PermanentErr - squash_noise computation failed. An infinite retry is done only for TransientErr
5e9ea06 to
7e7c3a9
Compare
fixes: https://github.com/zama-ai/fhevm-internal/issues/542
PBS computation can be in one of the following states:
squash_noisecomputation failed ordecompress_ctfailedAn infinite retry is done only for Transient Err
Additionally, both squash_noise and decompress_ct are wrapped to return an error if they would otherwise panic. This is done to avoid livelocks similar to the one noticed time ago in zkproof worker here