Selected independent review findings

These are selected findings with corresponding merged corrections, rather than a random sample or a count of all defects prevented.

Database connections held while polling has its own detailed record.

An older subscribe could undo a newer unsubscribe

PR #840. An older opt-in could finish after a newer opt-out and overwrite the user’s latest preference. The correction only lets a newer consent event update the saved preference, and the merged test exercises the concurrent-write ordering.

record_email_consent_event inserts the audit event and then unconditionally upserts user_email_preferences with that event. Because there is no per-user/topic lock before the event insert, two concurrent calls for the same user/topic can interleave as: older opt-in inserts, newer opt-out inserts and updates the preference, then the older opt-in resumes and overwrites the preference. That violates the spec’s latest-preference/send-guard and opt-out-override requirements. Lock the user/topic before inserting, or make the preference update conditional on the inserted event being newer than the current last_event_id/timestamp, and add a concurrency regression test.

Recorded review, final approval and merged code.

Duplicate prevention failed for simultaneous requests

PR #917. Two simultaneous requests with the same idempotency key could both launch a simulation before either recorded the key. The correction locks the key before checking and launching; a concurrent-request test checks that only one underlying enqueue occurs.

The idempotency lookup is performed and closed before the REST enqueue, and the idempotency row is only inserted after /api/runs or /api/runs/sweep has already accepted a run. Two concurrent requests with the same (service_key_id, tool_name, idempotency_key) can both miss the lookup, both enqueue, and only then race on create_mcp_idempotency_record. That violates the spec requirement that same-payload idempotent repeats do not enqueue a duplicate run. Reserve or lock the idempotency tuple before calling the REST enqueue, or otherwise make the lookup/enqueue/record sequence atomic.

Recorded review, final approval and merged code.

The duplicate-simulation and waiting-connection findings came from the same PR #917; they are not separate implementation runs.

Independent tests and review together

The simulation-semantics case preserves a failed semantic-contract test and four P1 review findings that were corrected before merge.