Diego ImbertandClaude Opus 5 8255f2ad2b fix(datatables): bounce the streams reading a data table when it is deleted ...

Deleting a governing data table, or the workspace that holds it, only collected
the fork pointers it stranded, for the warning. A Postgres trigger or capture
already streaming through one of those pointers kept the replication connection
it opened while the pointer still resolved, so it went on dispatching the
governing database's rows after the fork lost access — until its connection
happened to restart. The governing workspace's own streams on a deleted entry
did the same.

Both deletion paths now bounce the affected listeners inside their own
transaction, through the helper a permission change already uses, so a
listener that reconnects re-resolves the entry and finds it gone. The helper is
split so a caller can pass the (workspace, local name) pairs it already holds.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-17 10:01:15 +02:00

..

src

refactor: move integration tests to subcrates to reduce recompilation

2026-02-11 14:04:54 +00:00

tests

fix(datatables): bounce the streams reading a data table when it is deleted

2026-09-17 10:01:15 +02:00

Cargo.toml

fix: authenticate slack callback payload with per-workspace hmac (#9461)

2026-06-06 08:02:20 +00:00