ARCPClient.dispatch(envelope:) pushes job.result_chunk envelopes into a typed ResultChunkStream registered through client.resultChunks(for:) and then unconditionally yields the same envelope to unhandledContinuation at Sources/ARCP/Client/ARCPClient.swift:215. The public contract on ARCPClient.unhandled at Sources/ARCP/Client/ARCPClient.swift:36 is the "async stream of envelopes the client did not consume internally", so every other branch of the dispatcher (pong, job.accepted, job.completed, job.failed, job.cancelled) only falls back to unhandled when no internal consumer is registered. job.result_chunk is the lone exception, so a caller that registers a typed result-chunk consumer also sees every chunk a second time on client.unhandled, easily producing duplicate decoding work, double-charged metrics, or doubled side effects in user code that walks unhandled for telemetry.
Fix prompt: Make the .jobResultChunk arm of the dispatcher consistent with the other typed branches: only forward to unhandledContinuation when no ResultChunkStream is registered for the envelope's job id. Add a regression test that opens a result-chunk stream, sends a multi-chunk result, and asserts the typed stream receives every chunk while client.unhandled does not surface any of them; add a companion test for the opposite case where no consumer is registered and the chunks fall through to unhandled.
ARCPClient.dispatch(envelope:)pushesjob.result_chunkenvelopes into a typedResultChunkStreamregistered throughclient.resultChunks(for:)and then unconditionally yields the same envelope tounhandledContinuationatSources/ARCP/Client/ARCPClient.swift:215. The public contract onARCPClient.unhandledatSources/ARCP/Client/ARCPClient.swift:36is the "async stream of envelopes the client did not consume internally", so every other branch of the dispatcher (pong,job.accepted,job.completed,job.failed,job.cancelled) only falls back tounhandledwhen no internal consumer is registered.job.result_chunkis the lone exception, so a caller that registers a typed result-chunk consumer also sees every chunk a second time onclient.unhandled, easily producing duplicate decoding work, double-charged metrics, or doubled side effects in user code that walksunhandledfor telemetry.Fix prompt: Make the
.jobResultChunkarm of the dispatcher consistent with the other typed branches: only forward tounhandledContinuationwhen noResultChunkStreamis registered for the envelope's job id. Add a regression test that opens a result-chunk stream, sends a multi-chunk result, and asserts the typed stream receives every chunk whileclient.unhandleddoes not surface any of them; add a companion test for the opposite case where no consumer is registered and the chunks fall through tounhandled.