Skip to content

pm-dispatch: no read/status endpoint for launched or enqueued work (thin clients must cross domains for status) #5555

New issue
New issue
Open
Open
pm-dispatch: no read/status endpoint for launched or enqueued work (thin clients must cross domains for status)#5555
Assignees
dezren39
Labels
effort/mMedium: expected under 1 day of workkind/enhancementmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/normalOrdinary priority (the default)queue/parkedQueue task is parked (waiting on CI, time, or an event)status/parkedDeliberately paused with a recorded resume conditiontask/triageQueue packet kind: verify, reproduce, and route this itemwork/assignedQueue worker lifecycle state

Description

@developing-today
developing-today
bot
opened on Nov 4, 2026

Filed from fleet epic #5412 step 4 (#5432, the dispatch thin client), per that step's rule: interface gaps found while building the verbs are filed against pm-stack, not absorbed into the client.

Gap 1 — no read/status endpoint on pm-dispatch

pm-stack/dispatch/src/server.ts exposes exactly three routes: GET /health (unauthenticated), POST /v1/sessions, POST /v1/tasks. A caller that launched or enqueued work has no way to ask pm-dispatch about it afterwards — no GET /v1/tasks/<id>, no GET /v1/sessions/<id>. The thin client shipped in #5432 therefore answers "what happened to task N?" by crossing domains into the queue (fleet queue list / the queue store), which works but couples every dispatch caller to queue internals and to a second credential path.

A minimal fix on the pm-stack side would be one authenticated read route reusing the existing auth (authenticate() already gates the POSTs), e.g. GET /v1/tasks/:id returning the task row's status/worker/progress (the row dispatch itself created and claimed), and ideally GET /v1/sessions/:id proxying the session's existence/state from the OpenCode server. Read-only, no new write surface.

Gap 2 — DISPATCH_API_TOKEN had no by-name vault home (already fixed in the vault; recorded for the docs)

The dispatch README states pm-stack's secrets are filed in Bitwarden/1Password under dotted names. The bearer token was the exception: it existed only in the laptop's ~/secrets/dispatch.env, so the fleet-secrets resolver chain (the fleet's one secrets-by-name path) could not resolve it for a client. It has been filed in Bitwarden as pm-dispatch.api-token (value verified byte-identical to the service's, by hash) as part of #5432. The durable part of this gap is documentation: pm-stack/dispatch/install.sh / the dispatch README should name the token's vault home alongside the other pm-stack secrets so a future rotation updates both places.

Not gaps (checked and fine)

  • Auth shapes: the static bearer is sufficient for local clients; GitHub Actions OIDC remains the CI form.
  • Dedupe: POST /v1/tasks with a consumed dedupe_key returns the pre-existing task with pre_existing: true — exactly what a thin client needs.
  • The design note for the fleet epic claimed a rendered state dir at ~/.local/state/pm-dispatch/; none exists. Not a pm-stack defect — the note was wrong; corrected on fleet step 4: dispatch thin client domain over pm-stack #5432.

Acceptance criteria

  • pm-dispatch exposes an authenticated read route for a launched/enqueued task (and ideally a session) returning status/worker/progress
  • The dispatch README / install docs name the pm-dispatch.api-token vault home alongside the other pm-stack secrets
  • A thin client can answer "what happened to task N?" from pm-dispatch alone, without crossing into queue internals

Activity

  1. dezren39
    added
    kind/enhancement
    priority/normalOrdinary priority (the default)
    effort/mMedium: expected under 1 day of work
    status/needs-triageNot yet triaged; needs a first look
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Nov 4, 2026

  2. dezren39 commented on Nov 4, 2026

    @dezren39
    dezren39
    on Nov 4, 2026
    Member

    Intake review

    • Related issues/PRs: merged PRs with this issue number in the title: none found in a merged-PR title search — no merged PR explicitly resolves this issue, so it stays open.
    • Notes: Enriched by the fleet monitor (Duty 2, protocol §5): acceptance criteria appended to the body, labels normalized.
    • Risks / suggested approach: One authenticated GET route reusing the existing authenticate() in pm-stack/dispatch/src/server.ts; keep it read-only and return only the fields dispatch itself wrote. Gap 2 is already fixed in the vault — only its documentation remains.
  3. github-actions
    assigned
    dezren39
    on Nov 4, 2026
  4. dezren39
    added
    queue/queuedHas a queued task in the Supabase agent queue
    task/triageQueue packet kind: verify, reproduce, and route this item
    on Nov 5, 2026

  5. dezren39 commented on Nov 5, 2026

    @dezren39
    dezren39
    on Nov 5, 2026
    Member

    🤖 Agent note · handed off

  6. dezren39
    added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    work/assignedQueue worker lifecycle state
    and removed
    status/needs-triageNot yet triaged; needs a first look
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 5, 2026

  7. 144 remaining items

  8. dezren39
    added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    work/assignedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 6, 2026

  9. dezren39 commented on Nov 6, 2026

    @dezren39
    dezren39
    on Nov 6, 2026
    Member

    🤖 Agent note · handed off

  10. dezren39
    added
    queue/claimedQueue worker lifecycle state
    status/in-progressQueue worker lifecycle state
    and removed
    status/parkedDeliberately paused with a recorded resume condition
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    on Nov 6, 2026

  11. dezren39 commented on Nov 6, 2026

    @dezren39
    dezren39
    on Nov 6, 2026
    Member

    agent-note:v1

    • task: 10962
    • lane: code-f
    • event: handed_off
    • detail: Re-claimed by lane code-f; execution-lane assignment is opencode. Checkpointed handed_off for the opencode claimant. Attempts 4/4 AT CAP — claimant must bind this cycle or a cap raise is needed.

  12. dezren39 commented on Nov 6, 2026

    @dezren39
    dezren39
    on Nov 6, 2026
    Member

    🤖 Agent note · handed off

  13. dezren39
    added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    and removed
    queue/claimedQueue worker lifecycle state
    status/in-progressQueue worker lifecycle state
    on Nov 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

effort/mMedium: expected under 1 day of workkind/enhancementmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/normalOrdinary priority (the default)queue/parkedQueue task is parked (waiting on CI, time, or an event)status/parkedDeliberately paused with a recorded resume conditiontask/triageQueue packet kind: verify, reproduce, and route this itemwork/assignedQueue worker lifecycle state

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions