MyVideoGameList/myvideogamelist.com

Watch

Prevent duplicate Discord notifications for suspicious account registrations #1011

New issue

Closed

opened 2026-11-05 11:05:47 -06:00 by Codex · 2 comments

Codex commented

2026-11-05 11:05:47 -06:00

Member

Investigate the registration-to-Discord notification flow and make delivery idempotent so one suspicious account registration produces one notification.

Add regression coverage for the identified duplicate-dispatch path.

Scope

Trace suspicious-account detection, registration handling, Discord dispatch, and related tests.
Fix the repository-confirmed duplicate dispatch mechanism without changing unrelated notifications.
Add focused regression tests for single-delivery behavior.

Acceptance Criteria

A suspicious account registration results in exactly one Discord notification.
Repeated handling of the same registration cannot create duplicate Discord notifications.
Unrelated registration and notification behavior remains unchanged.

Test Coverage Required

Test the suspicious registration flow and assert one Discord notification dispatch.
Test the identified repeated-dispatch condition and assert duplicate delivery is prevented.

Progress Checklist

Inspect the registration and suspicious-account notification implementation.
Inspect existing notification and registration tests.
Implement the minimal duplicate-delivery fix.
Add regression coverage and verify the focused test suite.

Investigate the registration-to-Discord notification flow and make delivery idempotent so one suspicious account registration produces one notification. Add regression coverage for the identified duplicate-dispatch path. ## Scope - Trace suspicious-account detection, registration handling, Discord dispatch, and related tests. - Fix the repository-confirmed duplicate dispatch mechanism without changing unrelated notifications. - Add focused regression tests for single-delivery behavior. ## Acceptance Criteria - A suspicious account registration results in exactly one Discord notification. - Repeated handling of the same registration cannot create duplicate Discord notifications. - Unrelated registration and notification behavior remains unchanged. ## Test Coverage Required - Test the suspicious registration flow and assert one Discord notification dispatch. - Test the identified repeated-dispatch condition and assert duplicate delivery is prevented. ## Progress Checklist - [x] Inspect the registration and suspicious-account notification implementation. - [x] Inspect existing notification and registration tests. - [x] Implement the minimal duplicate-delivery fix. - [x] Add regression coverage and verify the focused test suite.

Codex added the

needs codex review

label

2026-11-05 11:05:47 -06:00

Codex changed title from ~~Determine Why Multiple Discord Notifications Are Sent for Newly Registered Suspicious Accounts~~ to Prevent duplicate Discord notifications for suspicious account registrations

2026-11-05 11:06:13 -06:00

Codex added

component: internal notifications

component: security

and removed

needs codex review

labels

2026-11-05 11:06:13 -06:00

jimmyb added this to the New Features - Part 1 project

2026-11-05 16:08:17 -06:00

Codex added

and removed

labels

2026-11-06 10:54:35 -06:00

Codex self-assigned this

2026-11-06 10:54:35 -06:00

Codex referenced this issue from a pull request that will close it,

2026-11-06 11:23:27 -06:00

Prevent duplicate suspicious registration alerts #1019

jimmyb closed this issue

2026-11-06 12:24:57 -06:00

Codex commented

2026-11-06 12:26:21 -06:00

Author

Member

Implemented and merged in PR #1019 (master merge commit 8f12bd45; implementation commit 84dcc917).

Suspicious-registration processing now locks the user row and reuses the existing security audit, preventing repeated handling from creating duplicate audits or jobs. Delivery locks and reloads the audit for each page, skips completed pages, and commits successful-page checkpoints separately so later failures resume correctly. Existing pagination, detection rules, payloads, mention suppression, and sanitized errors are preserved.

Concurrency review also reproduced a deadlock between distinct suspicious registrations. Database-only recording and registration transactions now retry up to three times. Turnstile verification and Fider provisioning are outside the retried transaction, alert dispatch remains after commit, and transactions containing Discord HTTP requests are never automatically retried.

Verification: all 134 focused tests passed on MariaDB 12.3 (1,435 assertions), including overlapping handlers/workers, independent registrations, deadlock recovery, synchronous delivery, and partial-page recovery. SQLite passed 129 tests with five MariaDB-only checks skipped. Pint, PHPStan, and diff checks passed. All four checklist items are complete.

One logical alert can span multiple Discord messages to preserve all matching-account details. Webhook acceptance followed by a lost response or worker crash remains an ambiguous delivery outcome; strict exactly-once delivery across that boundary is outside this fix's guarantee.

Deployment to development and production follows this closeout. No migrations, dependency changes, or frontend rebuilds are required.

Implemented and merged in PR #1019 (master merge commit `8f12bd45`; implementation commit `84dcc917`). Suspicious-registration processing now locks the user row and reuses the existing security audit, preventing repeated handling from creating duplicate audits or jobs. Delivery locks and reloads the audit for each page, skips completed pages, and commits successful-page checkpoints separately so later failures resume correctly. Existing pagination, detection rules, payloads, mention suppression, and sanitized errors are preserved. Concurrency review also reproduced a deadlock between distinct suspicious registrations. Database-only recording and registration transactions now retry up to three times. Turnstile verification and Fider provisioning are outside the retried transaction, alert dispatch remains after commit, and transactions containing Discord HTTP requests are never automatically retried. Verification: all 134 focused tests passed on MariaDB 12.3 (1,435 assertions), including overlapping handlers/workers, independent registrations, deadlock recovery, synchronous delivery, and partial-page recovery. SQLite passed 129 tests with five MariaDB-only checks skipped. Pint, PHPStan, and diff checks passed. All four checklist items are complete. One logical alert can span multiple Discord messages to preserve all matching-account details. Webhook acceptance followed by a lost response or worker crash remains an ambiguous delivery outcome; strict exactly-once delivery across that boundary is outside this fix's guarantee. Deployment to development and production follows this closeout. No migrations, dependency changes, or frontend rebuilds are required.

Codex added

and removed

labels

2026-11-06 12:26:22 -06:00

Codex commented

2026-11-06 12:29:24 -06:00

Author

Member

Deployed merged PR #1019 (8f12bd45) to development and production. Both release manifests now end in +pr1019-8f12bd45, and all three deployed runtime file SHA-256 checksums match the merged source.

Deployment verified each target environment/database and baseline checksum, retained file/release-manifest rollback backups, restarted both database queue workers, and gracefully reloaded PHP 8.5 FPM. Unrelated application/configuration/assets were checksum-guarded. No migrations, dependency changes, frontend rebuilds, or account/domain-data writes were performed.

HTTPS verification passed for home, login, and registration on both sites (HTTP 200); registration still includes the Turnstile control. Live suspicious accounts/Discord alerts were not generated during smoke checks; delivery behavior is covered by the mocked regression/concurrency tests described above.

Rollback backups:

Development: /home/mvgldev/deploy-backups/pr1019-8f12bd45-reizg7oc
Production: /home/mvgl/deploy-backups/pr1019-8f12bd45-2owmf8mc

Each deployment account retains ~/deploy-staging/pr1019-8f12bd45/deploy.py. For rollback, run it as that account with --rollback <corresponding-backup-path> and the account's PHP bin directory on PATH; it restores the three original files and release manifest and restarts the queue. Gracefully reload PHP 8.5 FPM afterward and repeat the HTTPS checks.

Deployed merged PR #1019 (`8f12bd45`) to development and production. Both release manifests now end in `+pr1019-8f12bd45`, and all three deployed runtime file SHA-256 checksums match the merged source. Deployment verified each target environment/database and baseline checksum, retained file/release-manifest rollback backups, restarted both database queue workers, and gracefully reloaded PHP 8.5 FPM. Unrelated application/configuration/assets were checksum-guarded. No migrations, dependency changes, frontend rebuilds, or account/domain-data writes were performed. HTTPS verification passed for home, login, and registration on both sites (HTTP 200); registration still includes the Turnstile control. Live suspicious accounts/Discord alerts were not generated during smoke checks; delivery behavior is covered by the mocked regression/concurrency tests described above. Rollback backups: - Development: `/home/mvgldev/deploy-backups/pr1019-8f12bd45-reizg7oc` - Production: `/home/mvgl/deploy-backups/pr1019-8f12bd45-2owmf8mc` Each deployment account retains `~/deploy-staging/pr1019-8f12bd45/deploy.py`. For rollback, run it as that account with `--rollback <corresponding-backup-path>` and the account's PHP bin directory on PATH; it restores the three original files and release manifest and restarts the queue. Gracefully reload PHP 8.5 FPM afterward and repeat the HTTPS checks.

Sign in to join this conversation.

No labels

component: admin dashboard

component: backend

component: billing

component: content management

component: faqs

component: game genres

component: game lists

component: game reviews

component: game search

component: games

component: internal notifications

component: platforms

component: security

component: tests

component: user api

component: user badges

component: user blogs

component: user consoles

component: user favorites

component: user friends

component: user notifications

component: user profiles

component: user site notifications

component: user wishlists

component: web design

security-hotspot

source: sonarqube

awaiting feedback

needs codex review

needs investigation

type: documentation

type: improvement

type: regression

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

MyVideoGameList/myvideogamelist.com#1011

No description provided.