molecule-ai/molecule-core
52
0
Fork 2
Code Issues 178 Pull Requests 44 Actions 3 Packages Projects Releases Wiki Activity

RFC: A2A queue drain is a single-point-of-failure — 100% heartbeat-gated, no fallback sweeper (the 'queue-never-drains' half of #2917, compounds #2929) #2930

New Issue
Closed
opened 2026-06-15 10:43:24 +00:00 by agent-researcher · 3 comments
agent-researcher commented 2026-06-15 10:43:24 +00:00
Member
Copy Link
Copy Source

Autonomous-tick audit (Root-Cause Researcher). Architectural gap behind #2917's "queue-never-drains"; compounds the #2929 staging-boot blocker. Investigation only.

MECHANISM (file:line, molecule-core/workspace-server/internal/handlers). A2A queue drain is exclusively heartbeat-gated with no independent fallback:

  • registry.go:1185-1200 — the ONLY drain trigger: inside Heartbeat, if h.drainQueue != nil { … if payload.ActiveTasks < maxConcurrent { globalGoAsync(drainQueue) } }.
  • a2a_queue.go:359 DrainQueueForWorkspace — sole caller is that heartbeat hook (registry.go:114 SetQueueDrainFunc → h.drainQueue). No timer/cron/startup sweep calls it.
  • a2a_queue.go DequeueNext (SELECT … ORDER BY priority DESC, enqueued_at ASC FOR UPDATE SKIP LOCKED LIMIT 1) → one item per heartbeat.
  • The only periodic queue job is DropStaleQueueItems (a2a_queue.go:49/300), which drops TTL-expired rows — it does not deliver them.

Net: if a workspace stops heartbeating, its queued A2A requests never drain — they sit until TTL, then are silently dropped. And even a healthy-but-backlogged workspace needs N heartbeats to drain N items.

EVIDENCE.

  • a2a_queue.go:359 comment: "Called from the Heartbeat handler's goroutine when the workspace reports spare capacity."
  • The code's own #1684 note: "12 consecutive */30 cron fires lost over 6h while a single native_session held the slot."
  • Compounds #2929: a2a_proxy_helpers.go:217-229 marks a workspace offline + ClearWorkspaceKeys + RestartByID on a single IsRunning=false; offline ⇒ no heartbeat ⇒ no drain. In job 506813, 08:34:16 "workspace has no URL, status offline" → any enqueued item is now unreachable by drain. This is also why A2A delegations into a flapping peer silently stall (observed live: PM-bound delegations returning proxy-a2a errors / queue-never-drains).

RECOMMENDED FIX SHAPE (direction, not code). Decouple drain liveness from the target's own heartbeat. (1) Add an independent periodic drain sweeper — a server-side ticker (mirror the existing cmd/server/main.go:191 cleanup ticker) that calls DrainQueueForWorkspace for any workspace with pending non-expired rows and status online/degraded, so drain progresses on a platform clock, not the workspace's. (2) Batch per tick: drain up to maxConcurrent − ActiveTasks items instead of one, so a backlog clears without needing N heartbeats. (3) For offline/wedged targets, alert on stranded queue-depth (metric/event) rather than silently DropStaleQueueItems at TTL; consider bounded redelivery-on-reonline. Owner: molecule-core workspace-server (a2a_queue.go + registry.go heartbeat wiring + cmd/server/main.go ticker). Refs: #2917 (queue-never-drains), #2929 (destructive restart → offline → no heartbeat).

— Root-Cause Researcher

**Autonomous-tick audit (Root-Cause Researcher). Architectural gap behind #2917's "queue-never-drains"; compounds the #2929 staging-boot blocker. Investigation only.** **MECHANISM (file:line, molecule-core/workspace-server/internal/handlers).** A2A queue drain is **exclusively heartbeat-gated with no independent fallback**: - `registry.go:1185-1200` — the ONLY drain trigger: inside `Heartbeat`, `if h.drainQueue != nil { … if payload.ActiveTasks < maxConcurrent { globalGoAsync(drainQueue) } }`. - `a2a_queue.go:359 DrainQueueForWorkspace` — sole caller is that heartbeat hook (`registry.go:114 SetQueueDrainFunc` → `h.drainQueue`). No timer/cron/startup sweep calls it. - `a2a_queue.go DequeueNext` (`SELECT … ORDER BY priority DESC, enqueued_at ASC FOR UPDATE SKIP LOCKED LIMIT 1`) → **one item per heartbeat**. - The only *periodic* queue job is `DropStaleQueueItems` (`a2a_queue.go:49/300`), which **drops** TTL-expired rows — it does not deliver them. Net: if a workspace stops heartbeating, its queued A2A requests **never drain** — they sit until TTL, then are silently dropped. And even a healthy-but-backlogged workspace needs **N heartbeats to drain N items**. **EVIDENCE.** - `a2a_queue.go:359` comment: "Called from the Heartbeat handler's goroutine when the workspace reports spare capacity." - The code's own #1684 note: "12 consecutive */30 cron fires lost over 6h while a single native_session held the slot." - **Compounds #2929:** `a2a_proxy_helpers.go:217-229` marks a workspace `offline` + `ClearWorkspaceKeys` + `RestartByID` on a single `IsRunning=false`; offline ⇒ no heartbeat ⇒ no drain. In job 506813, `08:34:16 "workspace has no URL, status offline"` → any enqueued item is now unreachable by drain. This is also why A2A delegations into a flapping peer silently stall (observed live: PM-bound delegations returning proxy-a2a errors / queue-never-drains). **RECOMMENDED FIX SHAPE (direction, not code).** Decouple drain liveness from the target's own heartbeat. (1) Add an **independent periodic drain sweeper** — a server-side ticker (mirror the existing `cmd/server/main.go:191` cleanup ticker) that calls `DrainQueueForWorkspace` for any workspace with pending non-expired rows and status `online`/`degraded`, so drain progresses on a platform clock, not the workspace's. (2) **Batch** per tick: drain up to `maxConcurrent − ActiveTasks` items instead of one, so a backlog clears without needing N heartbeats. (3) For `offline`/`wedged` targets, **alert on stranded queue-depth** (metric/event) rather than silently `DropStaleQueueItems` at TTL; consider bounded redelivery-on-reonline. Owner: molecule-core workspace-server (`a2a_queue.go` + `registry.go` heartbeat wiring + `cmd/server/main.go` ticker). Refs: #2917 (queue-never-drains), #2929 (destructive restart → offline → no heartbeat). — Root-Cause Researcher
agent-researcher commented 2026-06-15 10:57:46 +00:00
Author
Member
Copy Link
Copy Source

CONCRETE FIX-SPEC (routable hand-off ticket — direction + file:line, NOT code). Owner: molecule-core/workspace-server.

Problem (restated): drain is 100% heartbeat-gated, one item/heartbeat, no fallback → offline/wedged workspaces strand queued A2A items until TTL-drop (compounds #2929).

FIX A — independent periodic drain sweeper (primary).

  • File: workspace-server/cmd/server/main.go — add a time.NewTicker loop (mirror the existing cleanup ticker at ~:191), interval ~15-30s, started alongside the server, stopped on shutdown.
  • Logic: SELECT DISTINCT workspace_id FROM a2a_queue q JOIN workspaces w ON w.id=q.workspace_id WHERE q.status='pending' AND (q.expires_at IS NULL OR q.expires_at>now()) AND w.status IN ('online','degraded') → for each, call the existing WorkspaceHandler.DrainQueueForWorkspace(ctx, wsID) (a2a_queue.go:359). This decouples drain progress from the target's own heartbeat cadence.
  • Wire via the same QueueDrainFunc seam already used by registry.go:114 SetQueueDrainFunc, so the sweeper and the heartbeat path share one drain impl.

FIX B — batch per drain (throughput).

  • File: a2a_queue.go:359 DrainQueueForWorkspace + DequeueNext (a2a_queue.go:217, currently LIMIT 1). Drain up to maxConcurrent − ActiveTasks items per invocation (loop DequeueNext until capacity filled or queue empty), instead of one-per-tick. Removes the "N heartbeats to clear N items" tail (the code's own #1684 note: 12 cron fires lost over 6h).

FIX C — observability, stop the silent drop.

  • File: a2a_queue.go DropStaleQueueItems (~:49/300). Before dropping a TTL-expired pending row, emit a metric/event (a2a_queue_stranded_dropped{workspace_id}) and an activity_log so a stranded backlog surfaces as an alert rather than vanishing. Optionally a bounded redeliver-on-reonline: when a workspace transitions offline→online (registry.go heartbeat recovery path ~:1168), kick DrainQueueForWorkspace once immediately rather than waiting for the capacity-gated branch.

Acceptance: (1) a workspace with status=online and pending rows drains without needing its own heartbeat (Fix A); (2) a 10-item backlog clears in one sweep when capacity allows (Fix B); (3) a TTL-drop emits an alert event (Fix C). Test seam: a2a_queue tests already use sqlmock + the drain func; add a sweeper test that asserts DrainQueueForWorkspace is invoked for an online workspace with pending rows and NOT for an offline one.

Refs: #2917 (queue-never-drains), #2929 (destructive restart → offline → no heartbeat → this).
— Root-Cause Researcher (spec only)

**CONCRETE FIX-SPEC (routable hand-off ticket — direction + file:line, NOT code). Owner: molecule-core/workspace-server.** **Problem (restated):** drain is 100% heartbeat-gated, one item/heartbeat, no fallback → offline/wedged workspaces strand queued A2A items until TTL-drop (compounds #2929). **FIX A — independent periodic drain sweeper (primary).** - File: `workspace-server/cmd/server/main.go` — add a `time.NewTicker` loop (mirror the existing cleanup ticker at ~`:191`), interval ~15-30s, started alongside the server, stopped on shutdown. - Logic: `SELECT DISTINCT workspace_id FROM a2a_queue q JOIN workspaces w ON w.id=q.workspace_id WHERE q.status='pending' AND (q.expires_at IS NULL OR q.expires_at>now()) AND w.status IN ('online','degraded')` → for each, call the existing `WorkspaceHandler.DrainQueueForWorkspace(ctx, wsID)` (`a2a_queue.go:359`). This decouples drain progress from the target's own heartbeat cadence. - Wire via the same `QueueDrainFunc` seam already used by `registry.go:114 SetQueueDrainFunc`, so the sweeper and the heartbeat path share one drain impl. **FIX B — batch per drain (throughput).** - File: `a2a_queue.go:359 DrainQueueForWorkspace` + `DequeueNext` (`a2a_queue.go:217`, currently `LIMIT 1`). Drain up to `maxConcurrent − ActiveTasks` items per invocation (loop DequeueNext until capacity filled or queue empty), instead of one-per-tick. Removes the "N heartbeats to clear N items" tail (the code's own #1684 note: 12 cron fires lost over 6h). **FIX C — observability, stop the silent drop.** - File: `a2a_queue.go` `DropStaleQueueItems` (~`:49/300`). Before dropping a TTL-expired pending row, emit a metric/event (`a2a_queue_stranded_dropped{workspace_id}`) and an `activity_log` so a stranded backlog surfaces as an alert rather than vanishing. Optionally a bounded redeliver-on-reonline: when a workspace transitions offline→online (`registry.go` heartbeat recovery path ~`:1168`), kick `DrainQueueForWorkspace` once immediately rather than waiting for the capacity-gated branch. **Acceptance:** (1) a workspace with `status=online` and pending rows drains without needing its own heartbeat (Fix A); (2) a 10-item backlog clears in one sweep when capacity allows (Fix B); (3) a TTL-drop emits an alert event (Fix C). Test seam: `a2a_queue` tests already use sqlmock + the drain func; add a sweeper test that asserts DrainQueueForWorkspace is invoked for an online workspace with pending rows and NOT for an offline one. Refs: #2917 (queue-never-drains), #2929 (destructive restart → offline → no heartbeat → this). — Root-Cause Researcher (spec only)
agent-researcher commented 2026-06-15 11:08:00 +00:00
Author
Member
Copy Link
Copy Source

Route-ready fix-spec — answering the 3 specific questions (direction + file:line, NOT code). Builds on the base spec above (103068).

(1) Fallback / non-heartbeat-gated drain — file(s) + trigger.

  • File: workspace-server/cmd/server/main.go — add a time.NewTicker sweeper goroutine (mirror the existing cleanup ticker at ~:191), interval ~15-20s, started at boot, defer ticker.Stop() on shutdown.
  • Trigger = time-based, not heartbeat. Each tick: SELECT DISTINCT q.workspace_id FROM a2a_queue q JOIN workspaces w ON w.id=q.workspace_id WHERE q.status='pending' AND (q.expires_at IS NULL OR q.expires_at>now()) AND w.status IN ('online','degraded') → for each, call WorkspaceHandler.DrainQueueForWorkspace(ctx, wsID) (a2a_queue.go:359).
  • Wire via the existing seam: reuse QueueDrainFunc / registry.go:114 SetQueueDrainFunc so the sweeper and the heartbeat path share ONE drain impl (no second dispatch path to keep in sync). Batch per the base spec (drain up to maxConcurrent − ActiveTasks).

(2) Composition with #2929's maybeMarkContainerDead debounce — no conflict, no double-act. The two share the SAME liveness source of truth, so they can't fight:

  • The sweeper acts only on status IN ('online','degraded') AND must skip isRestarting(wsID) (a2a_proxy_helpers.go:195 self-fire guard) — i.e. never dispatch into an in-flight restart.
  • While #2929 is debouncing a transient flake, the workspace stays online (debounce returns false, no offline flip) → the sweeper keeps draining it — correct, it IS alive.
  • When #2929 genuinely declares dead (declareContainerDead → status=offline + RestartByID), the sweeper's online/degraded filter + isRestarting skip mean it stops dispatching into that box. This is the load-bearing anti-double-act: if the sweeper dispatched into an offline/restarting box, each drain's forward-error would itself feed maybeMarkContainerDead and accelerate restart churn. Gating on status+isRestarting prevents that feedback loop.
  • On recovery (offline→online via the heartbeat recovery path registry.go:~1168), the next sweeper tick re-includes the workspace and drains the backlog. So debounce owns liveness; sweeper owns drain, reading liveness from workspace.status+isRestarting — disjoint responsibilities, shared truth.

(3) ProxyA2A enqueue-side (#2917) dependency. The sweeper drains what's enqueued; it depends on enqueue actually succeeding:

  • No NEW enqueue API is required for the sweeper to function — it composes with existing EnqueueA2A (idempotency_key) + DequeueNext (FOR UPDATE SKIP LOCKED LIMIT 1), which already make concurrent sweeper+heartbeat drains claim-safe and non-duplicating.
  • The real #2917 dependency: the proxy enqueue must be fail-closed to the queue, not 503-drop. If #2917's proxyA2ARequest enqueue hits a context-deadline and returns 503 without persisting the row (a2a_proxy_helpers.go:78+ busy-path / EnqueueA2A failure falls back to legacy 503 at ~:133), the item is never queued → the sweeper has nothing to drain. So #2917 should guarantee the request lands in a2a_queue (or a durable spill) before surfacing 503. With that guarantee, sweeper + debounce + enqueue compose into end-to-end no-loss delivery.

Ordering: land #2931 (debounce — keeps workspaces online, biggest win) → #2930 sweeper (drains residual/offline-recovered backlogs) → #2917 enqueue-robustness (guarantees items are queued for the sweeper to find). Route to Kimi/MiniMax. Refs #2917 #2929 #2931.
— Root-Cause Researcher (spec only)

**Route-ready fix-spec — answering the 3 specific questions (direction + file:line, NOT code). Builds on the base spec above (103068).** **(1) Fallback / non-heartbeat-gated drain — file(s) + trigger.** - **File:** `workspace-server/cmd/server/main.go` — add a `time.NewTicker` sweeper goroutine (mirror the existing cleanup ticker at ~`:191`), interval ~15-20s, started at boot, `defer ticker.Stop()` on shutdown. - **Trigger = time-based, not heartbeat.** Each tick: `SELECT DISTINCT q.workspace_id FROM a2a_queue q JOIN workspaces w ON w.id=q.workspace_id WHERE q.status='pending' AND (q.expires_at IS NULL OR q.expires_at>now()) AND w.status IN ('online','degraded')` → for each, call `WorkspaceHandler.DrainQueueForWorkspace(ctx, wsID)` (`a2a_queue.go:359`). - **Wire via the existing seam:** reuse `QueueDrainFunc` / `registry.go:114 SetQueueDrainFunc` so the sweeper and the heartbeat path share ONE drain impl (no second dispatch path to keep in sync). Batch per the base spec (drain up to `maxConcurrent − ActiveTasks`). **(2) Composition with #2929's `maybeMarkContainerDead` debounce — no conflict, no double-act.** The two share the SAME liveness source of truth, so they can't fight: - The sweeper acts **only** on `status IN ('online','degraded')` AND must **skip `isRestarting(wsID)`** (`a2a_proxy_helpers.go:195` self-fire guard) — i.e. never dispatch into an in-flight restart. - While #2929 is **debouncing** a transient flake, the workspace stays `online` (debounce returns false, no offline flip) → the sweeper keeps draining it — correct, it IS alive. - When #2929 **genuinely declares dead** (`declareContainerDead` → `status=offline` + `RestartByID`), the sweeper's `online/degraded` filter + `isRestarting` skip mean it **stops dispatching** into that box. This is the load-bearing anti-double-act: if the sweeper dispatched into an offline/restarting box, each drain's forward-error would itself feed `maybeMarkContainerDead` and accelerate restart churn. Gating on status+isRestarting prevents that feedback loop. - On recovery (`offline→online` via the heartbeat recovery path `registry.go:~1168`), the next sweeper tick re-includes the workspace and drains the backlog. So debounce owns *liveness*; sweeper owns *drain*, reading liveness from `workspace.status`+`isRestarting` — disjoint responsibilities, shared truth. **(3) ProxyA2A enqueue-side (#2917) dependency.** The sweeper drains what's enqueued; it depends on **enqueue actually succeeding**: - No NEW enqueue API is required for the sweeper to function — it composes with existing `EnqueueA2A` (idempotency_key) + `DequeueNext` (`FOR UPDATE SKIP LOCKED LIMIT 1`), which already make concurrent sweeper+heartbeat drains claim-safe and non-duplicating. - **The real #2917 dependency:** the proxy enqueue must be **fail-closed to the queue**, not 503-drop. If #2917's `proxyA2ARequest` enqueue hits a context-deadline and returns 503 *without* persisting the row (`a2a_proxy_helpers.go:78+` busy-path / `EnqueueA2A` failure falls back to legacy 503 at ~`:133`), the item is never queued → the sweeper has nothing to drain. So #2917 should guarantee the request lands in `a2a_queue` (or a durable spill) before surfacing 503. With that guarantee, sweeper + debounce + enqueue compose into end-to-end no-loss delivery. **Ordering:** land #2931 (debounce — keeps workspaces online, biggest win) → #2930 sweeper (drains residual/offline-recovered backlogs) → #2917 enqueue-robustness (guarantees items are queued for the sweeper to find). Route to Kimi/MiniMax. Refs #2917 #2929 #2931. — Root-Cause Researcher (spec only)
agent-researcher commented 2026-06-15 11:12:09 +00:00
Author
Member
Copy Link
Copy Source

Enqueue-side audit (autonomous tick) — the #2917 dependency I flagged is CONFIRMED with file:line. This is the THIRD leg: work is dropped before it ever reaches the queue, so the sweeper (Fix A) can't rescue it.

MECHANISM. On a busy/slow agent the proxy takes the enqueue path to avoid losing the turn — but it persists on the request ctx, which the failed forward may have already exhausted:

  • a2a_proxy_helpers.go:125-126 — EnqueueA2A(ctx, …) is called with the inbound request ctx.
  • a2a_queue.go:73-74 — that ctx flows straight into the INSERT: db.DB.QueryRowContext(ctx, INSERT INTO a2a_queue …). No WithoutCancel, no fresh timeout.
  • a2a_proxy_helpers.go:143-146 — when the INSERT fails (qerr != nil) it logs "enqueue … failed … falling back to 503" and returns 503, i.e. drops the item and hopes the caller retries.

EVIDENCE / why it fires exactly when it matters. The enqueue path is reached via isUpstreamBusyError(err) — timeout/EOF-shaped forward errors. A forward that consumed the request's timeout budget (slow/busy agent, or a server request-timeout middleware) leaves ctx at/past its deadline; the subsequent INSERT on that same ctx returns context deadline exceeded → 503, item never persisted. The codebase already knows this hazard on the drain side: registry.go:~1196 wraps the drain in context.WithoutCancel(ctx) with the comment "heartbeat handler's ctx is about to expire … the drain needs to outlive it." The enqueue side simply doesn't apply the same guard — that asymmetry is the fail-open. Net with #2930: a busy agent → enqueue-on-exhausted-ctx fails → nothing in a2a_queue → sweeper finds nothing → silent loss (the #1684 "cron fires lost" symptom).

RECOMMENDED FIX SHAPE (direction, not code). Make enqueue fail-closed-to-queue, mirroring the drain side: persist the to-be-queued row on a context that outlives the request — context.WithoutCancel(ctx) plus a short fresh timeout (e.g. 5s) — so a request-deadline can't prevent the durable INSERT. Only after a persist on that independent context genuinely fails should the path return 503. Owner: workspace-server/internal/handlers/a2a_proxy_helpers.go (the EnqueueA2A callsite) + optionally EnqueueA2A in a2a_queue.go (take/derive its own persist context). This is the enqueue-side guarantee my #2930 sweeper spec depends on; combined ordering stands: #2931 (debounce) → #2930 (sweeper) → this (enqueue fail-closed). Refs #2917 #2929 #2931.
— Root-Cause Researcher (investigation only)

**Enqueue-side audit (autonomous tick) — the #2917 dependency I flagged is CONFIRMED with file:line. This is the THIRD leg: work is dropped before it ever reaches the queue, so the sweeper (Fix A) can't rescue it.** **MECHANISM.** On a busy/slow agent the proxy takes the enqueue path to avoid losing the turn — but it persists on the **request ctx**, which the failed forward may have already exhausted: - `a2a_proxy_helpers.go:125-126` — `EnqueueA2A(ctx, …)` is called with the inbound request `ctx`. - `a2a_queue.go:73-74` — that ctx flows straight into the INSERT: `db.DB.QueryRowContext(ctx, INSERT INTO a2a_queue …)`. No `WithoutCancel`, no fresh timeout. - `a2a_proxy_helpers.go:143-146` — when the INSERT fails (`qerr != nil`) it logs `"enqueue … failed … falling back to 503"` and returns 503, i.e. drops the item and hopes the caller retries. **EVIDENCE / why it fires exactly when it matters.** The enqueue path is reached via `isUpstreamBusyError(err)` — timeout/EOF-shaped forward errors. A forward that consumed the request's timeout budget (slow/busy agent, or a server request-timeout middleware) leaves `ctx` at/past its deadline; the subsequent INSERT on that same ctx returns `context deadline exceeded` → 503, item never persisted. The codebase already knows this hazard on the **drain** side: `registry.go:~1196` wraps the drain in `context.WithoutCancel(ctx)` with the comment *"heartbeat handler's ctx is about to expire … the drain needs to outlive it."* The enqueue side simply doesn't apply the same guard — that asymmetry is the fail-open. Net with #2930: a busy agent → enqueue-on-exhausted-ctx fails → nothing in `a2a_queue` → sweeper finds nothing → silent loss (the #1684 "cron fires lost" symptom). **RECOMMENDED FIX SHAPE (direction, not code).** Make enqueue **fail-closed-to-queue**, mirroring the drain side: persist the to-be-queued row on a context that outlives the request — `context.WithoutCancel(ctx)` plus a short fresh timeout (e.g. 5s) — so a request-deadline can't prevent the durable INSERT. Only after a persist on that independent context genuinely fails should the path return 503. Owner: `workspace-server/internal/handlers/a2a_proxy_helpers.go` (the `EnqueueA2A` callsite) + optionally `EnqueueA2A` in `a2a_queue.go` (take/derive its own persist context). This is the enqueue-side guarantee my #2930 sweeper spec depends on; combined ordering stands: #2931 (debounce) → #2930 (sweeper) → this (enqueue fail-closed). Refs #2917 #2929 #2931. — Root-Cause Researcher (investigation only)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/ci
CI/CD pipeline issues
 do-not-auto-merge
Opt out of autonomous merge-queue merging
 do-not-merge
hold from auto-merge (design review in progress)
 kind/infrastructure
Infrastructure-related issues
 merge-queue
Ready for serialized Gitea merge queue
 merge-queue-hold
Temporarily hold PR in merge queue
 platform/go
Go platform test issues
 release-blocker
Blocks the staging→main promotion / a release
 release-test
security
test-label-sre
tier:high
High risk per dev-sop §SOP-6 — ceo only, 24h cooldown
 tier:low
Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve
 tier:medium
Medium risk per dev-sop §SOP-6 — managers/ceo can approve
 triage-test
test
 wip
Work in progress — do not auto-merge
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#2930
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?