Context
Follow-up to PR #5182 (closed) and the jam recording that demonstrates the problem: https://jam.dev/c/eedf6a0d-6146-49e1-b934-958a6ee05a38
In the agent playground, a trigger (schedule or subscription) always resolves to the variant's latest revision at fire time. The backend resolves data.references (a variant-level id) to the head revision on every fire (triggers/service.py). But the playground card gives no indication of this: you can be looking at revision X while the trigger that "belongs" to it will actually fire revision X+2. There is no signal that the version you are viewing is not the version that runs.
PR #5182 attempted to fix the display side (scoping a trigger to the revision it was added on, so it stops appearing on every revision of the variant). That PR was closed in favor of handling the whole problem as one issue. The runtime binding itself is intentionally left as follow-latest; the gap is that the UI never tells the user which revision will actually run.
Requirements
- Show the trigger on the playground card (make it visible that a trigger exists for this variant/revision).
- Show which revision the trigger fires against. Because the binding follows the variant's latest revision, the card should surface the concrete revision that will run.
- Warn on mismatch. When the revision currently being viewed is not the revision the trigger will fire (i.e. you are on an older revision than the latest), show a clear warning that the trigger triggers a different version.
Related
Context
Follow-up to PR #5182 (closed) and the jam recording that demonstrates the problem: https://jam.dev/c/eedf6a0d-6146-49e1-b934-958a6ee05a38
In the agent playground, a trigger (schedule or subscription) always resolves to the variant's latest revision at fire time. The backend resolves
data.references(a variant-level id) to the head revision on every fire (triggers/service.py). But the playground card gives no indication of this: you can be looking at revision X while the trigger that "belongs" to it will actually fire revision X+2. There is no signal that the version you are viewing is not the version that runs.PR #5182 attempted to fix the display side (scoping a trigger to the revision it was added on, so it stops appearing on every revision of the variant). That PR was closed in favor of handling the whole problem as one issue. The runtime binding itself is intentionally left as follow-latest; the gap is that the UI never tells the user which revision will actually run.
Requirements
Related
docs(design): let triggers follow a variant's latest revision) — proposes a frontend "Latest" binding and a shared classifier for reading trigger references. This issue is the same underlying problem (surfacing which revision a trigger runs); the two should be reconciled together.