Captured as a phase-02 review follow-up (WR-01 finding in .planning/phases/02-test-coverage/02-REVIEW.md and 02-REVIEWS.md). Backlog Phase 999.3 in ROADMAP.md.
Problem
DatabaseRefreshTokenInfoService.FindByUserIdAsync (Sources/Libraries/ProjectV.DataAccessLayer/Services/Tokens/DatabaseRefreshTokenInfoService.cs:68) uses FirstOrDefaultAsync(token => token.UserId == rawUserId) while the parallel FindByUserNameAsync in DatabaseUserInfoService uses SingleOrDefaultAsync. The raw-SQL schema bootstrap in DbCollectionFixture.ApplySchemaAsync creates the tokens table without a UNIQUE constraint on user_name (which stores the user's Guid).
Two scenarios:
- If the design intent is one token per user (the production token-issuance flow deletes the old token before inserting a new one), the schema should enforce that invariant with
UNIQUE and the service should use SingleOrDefaultAsync so a duplicate-row bug surfaces immediately.
- If the design intent is multiple tokens per user (sliding window), the service should document it and add a test for the multi-token scenario.
The current state is asymmetric: enforcement is policy-only (service layer), and the integration tests do not exercise the duplicate-row case.
Acceptance Criteria
- Decide between Option A (UNIQUE + Single) and Option B (document multi-token intent + add test)
- Apply the chosen direction in production migration + the test schema in
DbCollectionFixture
- Add an integration test that exercises whichever invariant is chosen
Why deferred
This is an architectural decision requiring stakeholder input on token lifecycle policy — out of scope for Phase 2 (Test Coverage). The pre-existing production behavior (FirstOrDefaultAsync) is unchanged by Phase 2; this issue captures the gap for explicit resolution in a future milestone.
Related
- Phase 2 review:
.planning/phases/02-test-coverage/02-REVIEW.md (WR-01)
- Phase 2 review summary:
.planning/phases/02-test-coverage/02-REVIEWS.md
- Originally surfaced during 02-09 (dal-integration-testcontainers) plan execution
Captured as a phase-02 review follow-up (WR-01 finding in
.planning/phases/02-test-coverage/02-REVIEW.mdand02-REVIEWS.md). Backlog Phase 999.3 inROADMAP.md.Problem
DatabaseRefreshTokenInfoService.FindByUserIdAsync(Sources/Libraries/ProjectV.DataAccessLayer/Services/Tokens/DatabaseRefreshTokenInfoService.cs:68) usesFirstOrDefaultAsync(token => token.UserId == rawUserId)while the parallelFindByUserNameAsyncinDatabaseUserInfoServiceusesSingleOrDefaultAsync. The raw-SQL schema bootstrap inDbCollectionFixture.ApplySchemaAsynccreates thetokenstable without aUNIQUEconstraint onuser_name(which stores the user'sGuid).Two scenarios:
UNIQUEand the service should useSingleOrDefaultAsyncso a duplicate-row bug surfaces immediately.The current state is asymmetric: enforcement is policy-only (service layer), and the integration tests do not exercise the duplicate-row case.
Acceptance Criteria
DbCollectionFixtureWhy deferred
This is an architectural decision requiring stakeholder input on token lifecycle policy — out of scope for Phase 2 (Test Coverage). The pre-existing production behavior (
FirstOrDefaultAsync) is unchanged by Phase 2; this issue captures the gap for explicit resolution in a future milestone.Related
.planning/phases/02-test-coverage/02-REVIEW.md(WR-01).planning/phases/02-test-coverage/02-REVIEWS.md