Terminalize requests pinned to permanently unavailable agent versions
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- backend, distributed-systems
Research direction
Start at the invalid-pending-target reconciliation path and trace the existing request lifecycle conventions for terminal status and failure metadata. Add coverage for deleted agents, missing or retired exact versions, queue movement, temporary unavailability, and prevention of silent version substitution. Done means permanently unavailable pinned targets are terminalized while recoverable cases return to pending.
Written by the indexing model from the issue text.
Description
Problem
Scheduler reconciliation returns queued requests to pending when their selected registry target disappears or moves queues. Invalid pending targets are currently only logged and reported through telemetry.
A request explicitly pinned to an agent version that has been deleted, removed, or retired can therefore remain pending indefinitely unless that exact target is restored.
This was identified during review of #1381.
Expected behavior
Terminalize requests whose explicitly selected target is permanently unavailable, with a clear failure reason such as agent_version_unavailable.
Preserve recovery for cases that may become valid again:
- A version that moved to another queue should be returned to
pendingand dispatched to its current queue. - A temporary agent outage should remain recoverable.
- Requests must not be silently migrated to another agent version because that could change execution behavior and undermine benchmark reproducibility.
Implementation notes
Update invalid-pending-target reconciliation to distinguish permanent invalidity from temporary unavailability. Add coverage for:
- deleted agent
- missing or retired exact version
- queue movement
- temporary agent unavailability
- no silent version substitution
Keep the terminal status and failure metadata consistent with existing request lifecycle conventions.
- Dominant language
- TypeScript
- Stars
- 5
- Forks
- 5
- Avg merge
- 4d 19h
- Merged PRs (30d)
- 15
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/scope
-
type: worker-update
Difficulty 1/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
type: worker-update
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
type: worker-update
Difficulty 1/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
author: JaGord documentation good first issue UI
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
author: cedricvidal bug portal
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
Similar issues
-
triage
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
mermaid-js/mermaid-live-editor#2053 ·
Maintainers usually reply within 1 day
-
factory
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
jessepollak/home#1455 ·
Maintainers usually reply within 1 day
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
lingdojo/kana-dojo#31227 · 1 comment · 5 reactions ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
appandflow/stim#1838 ·
Maintainers usually reply within 1 day