On your own compute, event batches are tracked so dropped ones fail fast instead of hanging.
What's wrong with this entry?
The cloud worker client now reports every batch of durable session events as it moves through sending, accepted or failed, and maps the requests carried in a batch back to their callers so a request in a dropped batch is rejected with a delivery-specific error instead of staying pending forever. The reporting and drop handlers are optional arguments, and the only caller that supplies them gates them to sessions on your own compute, so an ordinary local or cloud session behaves exactly as before.
- Both handlers are installed only when the
CLAUDE_CODE_REMOTEenvironment variable is set andCLAUDE_CODE_ENVIRONMENT_KINDisbyoc, the setting for bring-your-own-compute runners; local CLI, ordinary cloud and Remote Control sessions keep the previous behaviour and the upload reporter returns immediately, leaving the bookkeeping invisible. - The drop handler fires when a batch is discarded on a 4xx response from the server, and the rejection error class reflects how far delivery got.
- Ephemeral batches are not reported, only durable ones.
- A handler that throws is caught and logged as a warning reading
CCRClient: onDurableEventsDropped threw; batch still dropped:, and the batch's fate is unchanged. - The gate as compiled is a zero-argument helper call that could in principle be a differently named check, but no competing definition appears in the file.
onDurableEventsDropped, CCRClient: onDurableEventsDropped threw; batch still dropped: , onDurableEventsUpload
Strings lifted out of the shipped bundle, so the claim above can be checked against them.