mirror of
https://github.com/block/buzz.git
synced 2026-10-29 13:31:44 +00:00
6766174673
Buzz must schedule mobile push notifications when it saves an eligible message. The relay, the server that receives and stores messages, now does this in application code. An older database trigger still exists. This trigger is a rule that runs automatically when a message is saved. This PR removes the old trigger and its supporting database function. The relay remains responsible for scheduling notifications. Migration 0063 makes this change in existing databases; updated setup scripts apply it to new databases. The change does not turn on push notifications. Production migration and deployment need separate approval. Before deployment, verify the release images and all pending database migrations. If push needs to be stopped after release, disable it with the feature flag and keep the qualified application version and database schema. Do not downgrade the application image. ### Validation - Local checks passed: 519 isolated database integration tests, 166 database unit tests, 17 source-policy tests, and the relay push-runtime tests. - Tests verify that the migration removes the old trigger, preserves earlier migration records, and lets the application schedule push work correctly. A concurrency test exercises the real application path; deliberately removing its lock makes the test fail. - [Current-head CI passed on retry](https://github.com/block/buzz/actions/runs/38752849383/attempts/2). The first attempt had one database-connection timeout during test setup; the failed jobs passed when rerun on the unchanged commit. - Initial local CI and push checks hit unrelated ACP test failures, which passed when run separately. Only the Rust-test push hook was skipped under the repository's local-check exception; other applicable hooks passed. ### Before merge - [x] Migration 0063 is available and the push trigger remains on [main at5397ea4](5397ea49e2). Recheck if main advances before merge. --------- Signed-off-by: Tom Brow <tomb@block.xyz>
21 lines
1.0 KiB
SQL
21 lines
1.0 KiB
SQL
CREATE CONSTRAINT TRIGGER events_refresh_channel_ttl
|
|
AFTER INSERT ON events
|
|
DEFERRABLE INITIALLY DEFERRED
|
|
FOR EACH ROW EXECUTE FUNCTION refresh_channel_ttl_after_event_insert();
|
|
CREATE TRIGGER trg_events_guard_channel_roster_snapshot
|
|
BEFORE INSERT ON events
|
|
FOR EACH ROW EXECUTE FUNCTION guard_channel_roster_snapshot();
|
|
|
|
-- INSERT OR UPDATE OF: an UPDATE can move a previously exempt row into the
|
|
-- guarded set (channel_id NULL -> NOT NULL) or move a channel row's
|
|
-- created_at below the fence, so both mutation paths re-run the guard on the
|
|
-- NEW row. A created_at rewrite that crosses partition bounds runs as
|
|
-- DELETE + INSERT and hits the cloned AFTER INSERT guard on the destination
|
|
-- partition; an in-partition rewrite fires the UPDATE OF arm.
|
|
CREATE CONSTRAINT TRIGGER events_created_at_floor
|
|
AFTER INSERT OR UPDATE OF created_at, channel_id ON events
|
|
DEFERRABLE INITIALLY DEFERRED
|
|
FOR EACH ROW
|
|
EXECUTE FUNCTION events_created_at_floor_guard();
|
|
SELECT attach_community_write_fence('events');
|