Summary
Implement stale-write detection for guild configuration updates so outdated submissions are rejected and superseded update attempts are marked as deprecated.
Problem
The specification requires guild configuration to become database-backed and editable by admins and guild owners. Once multiple actors can update config, concurrent writes can cause unsafe overwrites.
Auditing alone is not enough. The system also needs to prevent stale data from being accepted as the latest authoritative configuration.
Why This Matters
This protects:
- correctness of guild configuration
- admin trust in the web and bot config experience
- consistency of year reset, verification, and role mapping rules
- operational safety in a multi-tenant system
Without this, one admin can unknowingly overwrite newer config submitted by someone else.
Required Behavior
- Config updates must detect when submitted data is outdated.
- Outdated submissions must be rejected with a clear notification.
- Superseded submissions should be marked deprecated for traceability.
- The latest accepted config remains authoritative.
- This logic must work for both bot-side and future web/API config mutation paths.
Acceptance Criteria
- Updating config with stale data is rejected.
- User receives clear feedback that the config is no longer up to date.
- Superseded submission is recorded as deprecated.
- Latest accepted config remains unchanged by stale write attempts.
- Concurrency tests prove two overlapping submissions do not silently overwrite each other.
Suggested Implementation Targets
- src/services/PostgresDatabaseService.ts
- config command handlers
- future backend API config handlers
- prisma/schema.prisma
Suggested Technical Direction
Use optimistic concurrency for config updates with a version or revision token.
A config update request should include:
- guildId
- expected config revision
- submitted change set
- actor identity
If the stored revision no longer matches, reject the write and record the attempted superseded submission as deprecated.
Validation
- unit test: stale revision update is rejected
- unit test: current revision update succeeds
- integration test: overlapping updates preserve latest authoritative config
- integration test: deprecated superseded submission is queryable
- regression test: accepted update still writes audit trail correctly
Traceability
- Spec: docs/specs/issue-93-specification.md
- Matrix rule: TRC-017
- Related docs:
- docs/specs/traceability-matrix.md
- docs/specs/issue-drafts.md
- docs/specs/mvp-scope.md
Related Issues
Summary
Implement stale-write detection for guild configuration updates so outdated submissions are rejected and superseded update attempts are marked as deprecated.
Problem
The specification requires guild configuration to become database-backed and editable by admins and guild owners. Once multiple actors can update config, concurrent writes can cause unsafe overwrites.
Auditing alone is not enough. The system also needs to prevent stale data from being accepted as the latest authoritative configuration.
Why This Matters
This protects:
Without this, one admin can unknowingly overwrite newer config submitted by someone else.
Required Behavior
Acceptance Criteria
Suggested Implementation Targets
Suggested Technical Direction
Use optimistic concurrency for config updates with a version or revision token.
A config update request should include:
If the stored revision no longer matches, reject the write and record the attempted superseded submission as deprecated.
Validation
Traceability
Related Issues