fix: SettableAsyncResource clear callbacks if closed before set - #20074
fix: SettableAsyncResource clear callbacks if closed before set#20074clintropolis wants to merge 2 commits into
Conversation
FrankChen021
left a comment
There was a problem hiding this comment.
| Severity | Findings |
|---|---|
| P0 | 0 |
| P1 | 1 |
| P2 | 1 |
| P3 | 0 |
| Total | 2 |
Reviewed 3 of 3 changed files.
The review found one lifecycle hang and one cancellation-log regression.
This is an automated review by Codex GPT-5.6-Luna(max)
| // close() was called before set/setException. | ||
| result = null; | ||
| canceler = null; | ||
| readyCallbacks.clear(); |
There was a problem hiding this comment.
[P1] Closing can strand await callers
AsyncResource.await() registers a latch callback and blocks. Clearing callbacks on close removes that wake-up path; if close wins before completion, a late set or setException drains nothing, so an unbounded await blocks indefinitely and a timed await waits until its timeout. Add a close-aware wake-up path and a regression test.
There was a problem hiding this comment.
I think this is ok, the consumer is expected to call close to abandon an acquire, while the producer should only ever call set/setException, meaning that this should only be a problem in cases where there are multiple consumer threads I think? Nothing is using await in production currently, but added some javadoc to try to clear up the usage model.
There was a problem hiding this comment.
Reviewed 3 of 3 changed files.
The Javadocs clarify the intended usage model, but the lifecycle race remains: await() relies on a callback that close() now removes. An independent cancellation thread can therefore strand a single consumer in await() indefinitely. Please add a close-aware wake-up path and regression test.
capistrant
left a comment
There was a problem hiding this comment.
thanks for adding clarification in javadocs to help potential future callers understand expected use
FrankChen021
left a comment
There was a problem hiding this comment.
Reviewed 3 of 3 changed files for this follow-up.
The await lifecycle concern remains and was addressed in an inline reply; the prior logging concern is resolved by debug-only logging. No additional inline findings.
This is an automated review by Codex GPT-5.6-Luna(max)
Description
Fixes
SettableAsyncResourceto adhere to the contract of javadoc ofAsyncResource#addReadyCallbackwhere callbacks are not meant to be fired if close is called before set/setException. Not sure if this is causing any bugs, but plausible?