Skip to content

pm-dispatch: POST /v1/sessions and /v1/tasks return HTTP 502 (2026-11-04) #5647

Closed

Description

@dezren39

Problem

pm-dispatch (https://dispatch.security.cab) returned HTTP 502 for both dispatch endpoints on 2026-11-04, verified twice from GitHub Actions runs of developing-today/opencode's Daily Upstream Sync workflow after PR developing-today-forks/opencode#1671 merged:

  • Run 41902737337 (2026-11-04T20:02Z, head e4abd8c3): pm-dispatch-start: pm-dispatch POST /v1/sessions failed (HTTP 502); the failure-handoff step then also failed: pm-dispatch-queue: pm-dispatch POST /v1/tasks failed (HTTP 502).
  • Run 41903121391 (2026-11-04T20:05Z): identical HTTP 502 on both POST /v1/sessions and POST /v1/tasks.

Both runs got past job setup and action loading (the #4742 _staging defect those runs were verifying is fixed), minted the OIDC token, and reached the dispatch service — the 502 is from the service / its gateway, not the caller.

Impact

Every workflow that launches or queues work via pm-dispatch fails until the service recovers, and the failure-handoff path itself depends on the same service, so failures during an outage are not queued either.

Acceptance

  • POST /v1/sessions and POST /v1/tasks from a GitHub Actions OIDC caller return 2xx again (a dispatched Daily Upstream Sync run completing its dispatch step is sufficient evidence).
  • Root cause of the 2026-11-04 ~20:02–20:05Z 502s identified and noted here.

Filed by queue task 7519 (opencode #1519 verification) — that task is parked on this outage; its own staging fix is merged and proven.

Acceptance criteria

  • POST /v1/sessions and POST /v1/tasks from a GitHub Actions OIDC caller return 2xx again (a dispatched Daily Upstream Sync run completing its dispatch step is sufficient evidence).
  • Root cause of the 2026-11-04 ~20:02-20:05Z HTTP 502s is identified and recorded on this issue.
  • The failure-handoff path's dependence on the same service is dispositioned (documented as accepted risk, or a fallback is filed as a follow-up issue).

Activity

  1. added
    kind/bugSomething isn't working (prefixed form of the classic bug label)
    priority/highImportant and time-sensitive
    on Nov 4, 2026
  2. developing-today commented on Nov 4, 2026

    @developing-today
    Contributor
  3. added
    effort/mMedium: expected under 1 day of work
    source/queue-workerFiled or worked by the queue/worker pilot
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Nov 4, 2026
  4. dezren39 commented on Nov 4, 2026

    @dezren39
    MemberAuthor

    Intake review

    • Related: main CI failure: Daily Upstream Sync (OpenCode) (run 41903121391) developing-today-forks/opencode#1672 is the workflow-side failure track for the same outage (Daily Upstream Sync runs 41902737337 / 41903121391); opencode#1519 (closed) was the earlier, different failure mode and its verification task (queue task 7519) filed this issue and is parked on the outage.
    • Notes: Evidence is strong and current: two runs, minutes apart, both 502 on both endpoints after OIDC minting succeeded — the fault is in the service or its gateway, not the callers. The body's own ## Acceptance checklist is preserved above; the appended section restates it in the fleet's standard form.
    • Risks: The failure-handoff path depends on the same service, so outages are self-masking — no tracker gets queued while it is down.
    • Suggested approach: Check the dispatch service / gateway logs for the 20:02-20:05Z window first; if it was a deploy, correlate the deploy time before deeper debugging.
      — fleet monitor intake, 2026-11-04
  5. added
    queue/queuedHas a queued task in the Supabase agent queue
    task/triageQueue packet kind: verify, reproduce, and route this item
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 5, 2026
  6. 9 remaining items

  7. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked (task 10651, lane code-s)

    Root-cause fix opened as PR #6324: the pm-tunnel unit (nixos/services/pm-stack/default.nix) ran cloudflared with no --protocol flag — default QUIC — and the tunnel's QUIC connections are what drop on this host (no recent network activity, 2026-11-05T11:36Z, shortly before run 42023264697's edge 502s). PR #6324 switches the tunnel to --protocol http2 (TCP); flag placement verified against the deployed cloudflared 2026.10.7 binary.

    Resume condition: merge PR #6324, nixos-rebuild switch on the laptop, confirm the tunnel registers on http2 with no QUIC drop errors, then verify a real OIDC dispatch / Daily Upstream Sync run completes POST /v1/sessions with 2xx — only that run-level evidence closes this issue. Parked rather than held: the deploy restarts the fleet's tunnel and should ride a review of PR #6324 first.

  8. added
    queue/claimedQueue worker lifecycle state
    and removed
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    on Nov 5, 2026
  9. developing-today commented on Nov 5, 2026

    @developing-today
    Contributor

    🤖 Agent note · picked up (resume)

  10. added a commit that references this issue on Nov 5, 2026
  11. developing-today commented on Nov 5, 2026

    @developing-today
    Contributor

    🤖 Agent note · parked — merged, deploy blocked on interactive sudo (task 10651, lane code-k)

    Done this pass: PR #6324 merged — merge commit 1188e6ad24252d90e6823664f3704c6a6a5ddebe (verified fresh after merge). Laptop ~/git/code is already at that commit (pm-git-sync), and the merged nixos/services/pm-stack/default.nix carries --protocol http2 in the pm-tunnel ExecStart.

    Blocker: the running cloudflared (user unit pm-tunnel.service, home-manager managed) is still the pre-fix QUIC process. Activating the fix needs sudo nixos-rebuild switch --flake /home/user/code#amd on the laptop, and fleet sessions have no non-interactive sudo there (sudo: a password is required, no NOPASSWD rule, no standalone homeConfigurations output in the flake). A person at the laptop (or a root session) runs that one command; the tunnel unit restarts on HTTP/2.

    Resume condition (after the rebuild): confirm journalctl --user -u pm-tunnel shows tunnel connections registered with protocol http2 and no new QUIC drop errors; then run-level evidence per the acceptance criteria (OIDC dispatch or next Daily Upstream Sync completes POST /v1/sessions with 2xx) — #5647 closes only on that evidence.

  12. 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
    on Nov 5, 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/bugSomething isn't working (prefixed form of the classic bug label)meta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/highImportant and time-sensitivequeue/parkedQueue task is parked (waiting on CI, time, or an event)source/queue-workerFiled or worked by the queue/worker pilotstatus/parkedDeliberately paused with a recorded resume conditionstatus:donetask/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