When a run is queued with a forced snippet or skill and that record is switched off before the run starts, the source is dropped and nothing says so. The run then does not do what the person who queued it asked for, and the only way to find out is to compare the request against the transcript.
This has always been true for snippets — AgentRunRequestCodec::snippetsByUids() has gone through the active-only lookup since it was written. #781 asked for the two source kinds to stop disagreeing, and PR #810 does that by giving skills the same rule. So the inconsistency is gone and the silence is now uniform, which is why it gets its own issue rather than staying a clause in that one.
Why this is not just logging
A log line answers "did it happen", which matters for support. It does not answer the question the operator actually has, which is "why did this run behave differently from the one I queued". That question is asked at the run, not at the log, so the answer has to live where the run is read.
The shape that already exists in this codebase is ADR-121's dropped_turns, recorded on the user line of a conversation whose context window overflowed. It is the same class of event: something the caller supplied did not reach the model, recorded next to the thing it happened to.
What has to be decided
- Where it is recorded. On the run record, so the runs module can show it; or in the injected-context readout, next to the sources that did make it. The second is where a reader is already looking at the forced set.
- Whether a dropped forced source should ever refuse the run instead. For a queued run this is defensible in a way it is not for a resume: nothing has been sent yet, so refusing costs nothing but a message. ADR-165 deliberately does not refuse a resume over a missing source, and that reasoning does not carry over.
- Whether "deleted" and "switched off" should read differently. Both resolve to nothing today. They are different operator actions and a reader would want to tell them apart.
Scope
Both source kinds and both composition paths — the playground's synchronous send and the queued run's dequeue. The resume path is out of scope: ADR-166 and ADR-175 keep a deactivated source resolving there on purpose, so nothing is dropped and there is nothing to report.
Split out of #781. Ref ADR-121, ADR-165, ADR-166.
When a run is queued with a forced snippet or skill and that record is switched off before the run starts, the source is dropped and nothing says so. The run then does not do what the person who queued it asked for, and the only way to find out is to compare the request against the transcript.
This has always been true for snippets —
AgentRunRequestCodec::snippetsByUids()has gone through the active-only lookup since it was written. #781 asked for the two source kinds to stop disagreeing, and PR #810 does that by giving skills the same rule. So the inconsistency is gone and the silence is now uniform, which is why it gets its own issue rather than staying a clause in that one.Why this is not just logging
A log line answers "did it happen", which matters for support. It does not answer the question the operator actually has, which is "why did this run behave differently from the one I queued". That question is asked at the run, not at the log, so the answer has to live where the run is read.
The shape that already exists in this codebase is ADR-121's
dropped_turns, recorded on the user line of a conversation whose context window overflowed. It is the same class of event: something the caller supplied did not reach the model, recorded next to the thing it happened to.What has to be decided
Scope
Both source kinds and both composition paths — the playground's synchronous send and the queued run's dequeue. The resume path is out of scope: ADR-166 and ADR-175 keep a deactivated source resolving there on purpose, so nothing is dropped and there is nothing to report.
Split out of #781. Ref ADR-121, ADR-165, ADR-166.