Repository navigation
Plan: community-threads priorities and evidence-led pgflow adoption #710
Description
Outcome
Use community-threads to decide whether pgflow removes enough orchestration code, without weakening application behavior or safety. Keep application rollout and pgflow adoption separate: onboarding users and collecting feedback must not wait for a pgflow migration or a new engine roadmap.
This is the ordered coordination plan, not an implementation specification or approval for production changes. No deadline is assigned to pgflow adoption.
Priority and delivery order
| Order | Deliverable | Exit check |
|---|---|---|
| 1 — current product priority | Support use of the existing community-threads behavior and collect real feedback. Keep route-changing Move/Ignore corrections disabled initially. | The application team can onboard users without a pgflow migration or correction enablement. Record concrete problems and repeated feedback before selecting further product changes. |
| 2 — next pgflow action | Agree one bounded, throwaway application proof and its behavior matrix. | A scoped execution issue names the exact application/pgflow revisions, preserved semantics, deterministic checks, and exclusions. The expanded proof proposal below is not yet an approved scope. |
| 3 — evidence | Run that proof against one exact pgflow candidate and measure orchestration removed versus adapters and domain guards retained. | Runnable evidence covers the selected success, failure, retry, ambiguity, concurrency, and worker-loss cases. Publish an explicit adopt / revise / stop recommendation with known gaps. A failed parity check is a valid result. |
| 4 — conditional fixes | Implement only the smallest demonstrated blockers, one delivery at a time; repeat affected proof checks. | Each fix links to a failed behavior check or a concrete operational requirement. No broad feature bundle becomes an implicit prerequisite. |
| 5 — adoption/release decision | Reconcile the result with #653's exact-candidate validation and release gate. Decide separately whether to propose a production migration. | The candidate, package versions, final migration artifact, operational changes, and remaining gaps are explicit. Any release, hosted migration, deployment, or correction enablement needs its own approval. |
The application team's deployment preparation remains outside this pgflow issue. Keeping corrections disabled does not cancel or close the application's correction work; it separates implementation/readiness from enablement. Collect feedback for a period before reconsidering product behavior; this does not set a pgflow delivery deadline.
First proof: scope decision, not a migration promise
The earlier Help/Ignore-only spike in supabase-community/community-threads#27 closed without an evaluation result. It is historical input, not evidence that pgflow fits the application.
The proposed stronger first proof is one thin intake-to-delivery slice that checks transactional acceptance, independent Support/Help outcomes, and Support's first recorded attempt before Help, not Support success before Help. Include classified retry/stop/uncertainty and honest terminal recovery. Choose explicitly between that proposal, a deliberately narrower experiment, or broader workflow coverage before implementation.
Retain authoritative business state, exact receipts, exclusive claims, uncertainty, and transition guards in the application. Existing transition queries include old queue effects: do not reuse message IDs against the wrong queue or copy those effects unchanged. Measure the adapter cost rather than hiding it.
Keep feedback/Boost and the planned correction post/activate/delete workflow in the fit matrix. A narrow proof does not certify their migration. Do not run live Slack writes, paid classifiers, hosted repairs, production cutover, or historical replay as part of the proof.
Existing work: completed, conditional, and parked
- Completed foundation: Fix shared worker result boundaries, falsy outputs, and shutdown classification #701 merged through fix(worker): preserve outcomes across result reporting failures #708. Worker result reporting preserves handler outcomes and falsy outputs. Do not repeat this work.
- First retry-parity candidate: Allow flow handlers to select the next retry delay #655, handler-selected next retry delay, when the selected proof needs provider
Retry-After. Keep attempt accounting unchanged. Reconcile the separately selected strict persisted not-before/claim-time guard before claiming that stronger guarantee; the current issue body does not specify it. No free deferrals or retry-policy redesign. - Recovery/startup/runtime candidates: Terminalize tasks after the stalled-task requeue limit #689 for stalled-task terminal outcomes; Prevent duplicate pending worker starts with invocation IDs and acknowledgements #696 when HTTP-supervised worker startup is in scope; Diagnose and fix intermittent Supabase concurrency stall in portable-runtime E2E #694 for the applicable Supabase runtime investigation. None is an unconditional prerequisite to starting an honest proof. Engine terminalization alone does not settle application-domain work.
- Effect-safety and arithmetic candidates: retain application uncertainty guards; consider Investigate safe handling of uncertain external effects across retries and worker recovery #698 only where proof shows a remaining retry/recovery effect gap. Design strict worker ownership and fencing for safe automatic replacement #697/Use terminal events to cooperatively abort in-flight worker tasks #646 do not establish whether a remote effect happened. Bug: Exponential backoff overflow and unbounded retry delays #271 remains valid independent retry-arithmetic hardening, not an automatic adoption prerequisite.
- Parked for this adoption plan: stateful Dirty Runs (Epic: prove bounded full-schema Dirty Runs A → B correctness #699 and Dirty Runs: freeze the bounded A → B protocol and proof envelope #700/Dirty Runs: add real schema state and isolate v2 from legacy writers #702–Dirty Runs: connect the typed worker path and close the A → B evidence gate #706), free deferrals, aliases Add stable flow aliases through DeployedFlow startup deployment #648, shared queues Add explicit shared queues with multi-flow dispatch #652, and broad restart/resume/wait/signal work (Retry failed runs as fresh runs with explicit restart lineage #657/Resume failed runs by reusing every completed task #658/Design queue-less manual completion tasks (
queue: false) #661/Support durable external signals for waiting flow steps #660). Revisit only against concrete demonstrated need; they are not promised next deliveries. Existing issue labels are not rewritten by this roadmap.
Private per-step queues already exist in the inspected candidate; #653 still owns downstream evidence and the combined release gate. Neither shared queues nor aliases are prerequisites. Shared concurrency is not provider pacing, cooldown coordination, or proof of safe replay.
Completion checklist
- Record the application-first priority and the independent pgflow evaluation track.
- Record Fix shared worker result boundaries, falsy outputs, and shutdown classification #701 as completed and distinguish conditional fixes from deferred work.
- Agree first-proof scope and create its bounded execution issue.
- Record runnable evidence and an adopt/revise/stop result against an exact candidate.
- Resolve only demonstrated blockers, reconcile Epic: staged private per-step queues and queue identity #653, and record the resulting adoption/release decision.
This issue coordinates order and evidence. It does not replace linked implementation specs, approve unfinished design decisions, automatically reopen community-threads#27, or authorize releases or production operations.
Activity