Skip to content

github-ci Worker cannot reach the queue broker /events-append (tailnet-only) — public broker route needed for the #5693 sink design #6925

Open

Description

@dezren39

Gap found during the #5693 build (2026-11-07)

The #5693 design routes the github-ci Worker's push / pull_request / issues events through the queue broker: POST /events-append (the #5690 sink), so no third sink implementation exists.

The broker is unreachable from a Cloudflare Worker. The production queue broker listens on the tailnet only (100.99.113.103:4801 + UDS, per doc/fleet/queue-turso-cutover.md). It has no public route: the only Cloudflare Tunnel on the laptop (pm-tunnel) serves the pm stack, and the atlas-search tunnel pattern (a *.security.cab hostname + Access service token) has no broker equivalent.

What the Worker does until this lands

pkgs/github-ci/worker/src/sink.ts: when EVENTS_BROKER_URL is set, the Worker POSTs to {EVENTS_BROKER_URL}/events-append. Until then it performs the sink write itself — the exact INSERT INTO events statement the broker's verb_events_append executes (turso_queue.rs), same table (fleet-queue events), same row shape (worker_id github-webhook, task_id NULL, whole-second Z created_at). One sink, one table; the Worker is a client of the sink's semantics, not a third sink. Verified live 2026-11-07 (push + issues smoke events read back from fleet-queue events).

Acceptance

  • A public, authenticated route to the queue broker exists (e.g. a queue-broker.security.cab tunnel hostname gated by a Cloudflare Access service token, following the atlas-search pattern in pkgs/atlas-search), OR an equivalent documented route.
  • EVENTS_BROKER_URL (+ token, if the route needs one) is set on the github-ci Worker; a replayed push smoke lands its event row via the broker path.
  • The direct-Turso fallback in sink.ts stays as the outage fallback, documented as such.

Refs #5693, #5690.

Acceptance criteria

  • A public, authenticated route to the queue broker exists (e.g. a queue-broker tunnel hostname gated by a Cloudflare Access service token, following the atlas-search pattern), or an equivalent documented route.
  • EVENTS_BROKER_URL (and the token, if the route needs one) is set on the github-ci Worker, and a replayed push smoke event lands via the broker path and is read back from the fleet-queue events table.
  • The direct-Turso fallback in sink.ts remains in place and is documented as the outage fallback.

Activity

  1. developing-today commented on Nov 7, 2026

    @developing-today
    Contributor
  2. added
    kind/infrastructureInfrastructure / host-portability work
    priority/normalOrdinary priority (the default)
    effort/mMedium: expected under 1 day of work
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Nov 7, 2026
  3. dezren39 commented on Nov 7, 2026

    @dezren39
    MemberAuthor

    Intake review

    Fleet monitor intake (2026-11-07). Verified still live this run: the issue was filed today during the #5693 build; the Worker's direct-Turso fallback was verified live today (push + issues smoke events read back), and no merged PR or existing route gives the Worker a public path to the tailnet-only broker — the gap is real and current.

    • Related: design: move ci.events webhook ledger from Supabase to Turso staging #5693 (the design that routes Worker events through the broker sink), design: move agent append streams (agent.events, agent.quota_records) from Supabase to Turso staging #5690 (the sink), the atlas-search tunnel pattern in pkgs/atlas-search.
    • Notes: Until this lands, the Worker performs the sink write itself with the same statement and row shape as the broker verb — one sink semantics, two writers. That works, but it means the broker's auth/validation path is bypassed for these events.
    • Risks: a public broker route widens the attack surface — it must be authenticated (Access service token) and append-only for this use. Creating the tunnel/Access application needs Cloudflare account access, which may make this operator-assisted rather than purely queue work.
    • Suggested approach: mirror the atlas-search pattern (tunnel hostname + Access service token), set EVENTS_BROKER_URL on the Worker, replay a push smoke event and read it back from the fleet-queue events table, keep the direct-Turso path as the documented outage fallback.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    effort/mMedium: expected under 1 day of workkind/infrastructureInfrastructure / host-portability workmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedmeta/follow-upFollow-up spun out of earlier workpriority/normalOrdinary priority (the default)status/needs-triageNot yet triaged; needs a first look

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions