Fix ExternalPusherImpl so it doesn't care about ordering.#6607
Conversation
|
ProviderModelNotFoundError |
|
@kentonv Bonk workflow failed. Check the logs for details. View workflow run · To retry, trigger Bonk again. |
038de1e to
fc8809d
Compare
|
/bonk retry review |
There was a problem hiding this comment.
- [LOW] Stale ordering comment in
worker-interface.capnp— the comment on line 596-597 still claims externals must be pushed before the JsValue, but this PR explicitly removes that requirement. See inline comment. - [LOW] Minor typo in
pushAbortSignalcomment: "the the" → "the".
This review was written by an AI assistant and may contain mistakes. Please verify any suggestions before applying.
|
Stale comment in
This is no longer accurate after this PR — the implementation now handles either ordering. Consider updating this comment. |
|
Review posted on PR #6607. Here's a summary of my analysis: Overall: This is a well-structured fix. The core change replaces Key observations:
Two minor findings posted:
|
Previously, `ExternalPusherImpl` _assumed_ that the `push` RPC would always be received before the corresponding `unwrap` method was called during deserialization. We seem to have cases in production where this assumption isn't holding. It turns out, though, we don't have to make the assumption. We can actually deal with the push coming after the unwrap just fine, if we are clever. Honestly, I had a feeling I'd burn myself trying to create `tryGetLocalServerSync()`...
fc8809d to
577d2d4
Compare
Previously,
ExternalPusherImplassumed that thepushRPC would always be received before the correspondingunwrapmethod was called during deserialization.We seem to have cases in production where this assumption isn't holding.
It turns out, though, we don't have to make the assumption. We can actually deal with the push coming after the unwrap just fine, if we are clever.
Honestly, I had a feeling I'd burn myself trying to create
tryGetLocalServerSync()...