feat(workspaces): update_tier column for canary vs production fan-out #124
dev-lead
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "feat/canary-tier-filter"
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?
Summary
Schema-only foundation for core#115 canary tier filter. Adds
update_tiercolumn to workspaces table, defaultproduction, allowed valuescanary|production. The apply-endpoint filter that reads this column lands with core#123 (drift detector + queue + apply, the deferred follow-up of core#113).Default-safe
productionis the default → existing customers (Reno-Stars + any future tenant) are default-safe. Synthetic dogfooding workspaces opt INTOcanaryexplicitly via PATCH (separate change with the apply endpoint).What this does NOT do
These all land in core#123.
Phase 4 self-review (five-axis)
Correctness: No finding —
IF NOT EXISTSguards,DEFAULTclause means existing rows getproductionon migration apply.Readability: No finding — comment documents tier semantics + deferral to core#123.
Architecture: No finding — additive ALTER, partial index for the expected canary-bias query pattern.
Security: No finding — column constraint reduces blast radius of bad PATCH input.
Performance: No finding — partial index minimizes write amplification on production-default rows.
Refs
Closes core#115 partial. Schema-only change; the apply-endpoint filter logic that reads this column lands with core#123 (drift detector + queue + apply endpoint, the deferred follow-up of core#113). Default 'production' so existing customers (Reno-Stars + any future tenant) are default-safe. Synthetic dogfooding workspaces opt INTO 'canary' explicitly. CHECK constraint pins the closed value set ('canary' | 'production') — the apply endpoint's filter relies on the database to reject anything else, so a future operator typo in PATCH /workspaces/:id ({update_tier: 'canery'}) returns a constraint violation, not silent fan-out to nobody. Partial index on canary rows since the apply-endpoint query path ('apply this update only to canary tier first') hits canary much more often than production, and the production set is the much larger default. WHAT THIS DOES NOT DO (lands with core#123) - PATCH endpoint to flip a workspace to canary - The apply endpoint that consults the column - Tests that exercise canary-vs-production fan-out Schema-only foundation; same pattern as core#113 (workspace_plugins). PHASE 4 SELF-REVIEW Correctness: No finding — IF NOT EXISTS guards, DEFAULT clause means existing rows get 'production' on migration apply. Readability: No finding — comment block documents the tier semantics + the deferral to core#123. Architecture: No finding — additive ALTER, partial index for the expected access pattern. Security: No finding — no code path; column constraint reduces blast radius of bad PATCH input. Performance: No finding — partial index minimizes write amplification on the production-default rows. REFS core#115 — this issue core#123 — apply endpoint follow-up (will exercise this column) core#113 — version subscription DB foundation (sibling pattern) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>Phase-4 in body. Schema-only; behavior in core#123.