You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(apps): cascade application deletes and make release transitions atomic
Application ids are client-supplied, and deleting an app removed only the parent
row. Versions, budgets, invocations and pinned graphs had no ownership column and
no cascading foreign key, so a user who knew a deleted app's id could recreate it
under their own account: the ownership check passed against the new parent row
while the child reads returned the previous owner's orphaned releases and usage.
Child tables now carry real foreign keys with ON DELETE CASCADE, and delete runs
as one transaction that erases children explicitly -- foreign key enforcement is
per connection, so the cascade is declared and performed rather than assumed.
application_versions and application_invocations gained a user_id stamped from
the parent, and the reads that take only an application id can now filter on it;
the tRPC router and the websocket runner pass the caller's id. Ids are validated
and claimed through an insert that fails on reuse instead of an upsert, so a
released id cannot be taken over. A migration deletes orphans, backfills user_id,
and rebuilds the tables with the constraints.
Publishing read MAX(version), cleared the released flag and inserted the new row
as separate statements, with nothing in the schema forbidding a duplicate version
or a second released row -- concurrent publishes could produce either, leaving
the released lookup to pick arbitrarily. Each transition is now one transaction,
(application_id, version) is unique, and the lookup orders by version. Rollback
verifies the target exists before clearing anything, so a bad version number no
longer leaves the app with nothing released.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011Su7dXD6fnXtKKbdCcM2vS
0 commit comments