fix(testing): recover from lock poisoning in memoized! macro to preve… - #5846
Conversation
|
|
|
Hi @rohanranjan0902, can you re-author these commits in a way that is linked to your github user, so that the CLA check can run properly? We don't merge community PRs without a signed CLA. |
|
Also, I would not say it's accurate to say that this fixes any CI flakes, since the nature of this error is that it only happens when there has already been a previous failure. |
99cc590 to
30242f4
Compare
|
Hi @bfops , thanks for the review! I've made the updates you requested:
Let me know if there's anything else you need before this is ready to merge! |
bfops
left a comment
bfops
left a comment
There was a problem hiding this comment.
Seems good to me! Thank you!
|
@rohanranjan0902 are you able to make these verified commits? If not I can have our bot re-author them. |
…lockworklabs#5841) When a previous test panics while compiling a module, the cache Mutex becomes poisoned. This replaces .unwrap() with .unwrap_or_else() to recover the lock, ensuring subsequent tests surface their actual underlying errors rather than failing with a cascade of generic PoisonErrors.
Head branch was pushed to by a user without write access
2457747 to
be130ff
Compare
|
@bfops I’ve recreated the PR commit as an SSH-signed commit linked to my GitHub account and force-pushed it as "be130ffb8". The signature verifies locally. I noticed GitHub automatically disabled auto-merge after the force-push. Could you please re-enable auto-merge when convenient? |
|
Great, thank you! I'll merge once the CI passes. |
3 participants
This PR allows the test harness to gracefully recover from lock poisoning (Issue #5841).
Previously, if a test panicked while compiling a module inside the memoized! macro, it would poison the Mutex holding the MEMOIZED compilation cache. Any subsequent tests attempting to access the cache would panic with a PoisonError, causing unrelated tests to fail and masking the original error.
This replaces .lock().unwrap() with .lock().unwrap_or_else(|e| e.into_inner()) on the cache mutex. This safely recovers the lock after a panic, allowing unrelated tests to continue compiling and running their own modules instead of failing in cascade.
Rollback safety impact
n/a