support_backend/specs/016-load-concurrency-testing/checklists/requirements.md

# Specification Quality Checklist: Load and Concurrency Testing

**Purpose**: Validate specification completeness and quality before proceeding to planning
**Created**: 2026-09-09
**Feature**: [spec.md](../spec.md)

## Content Quality

- [x] No implementation details (languages, frameworks, APIs)
- [x] Focused on user value and business needs
- [x] Written for non-technical stakeholders
- [x] All mandatory sections completed

## Requirement Completeness

- [x] No [NEEDS CLARIFICATION] markers remain
- [x] Requirements are testable and unambiguous
- [x] Success criteria are measurable
- [x] Success criteria are technology-agnostic (no implementation details)
- [x] All acceptance scenarios are defined
- [x] Edge cases are identified
- [x] Scope is clearly bounded
- [x] Dependencies and assumptions identified

## Feature Readiness

- [x] All functional requirements have clear acceptance criteria
- [x] User scenarios cover primary flows
- [x] Feature meets measurable outcomes defined in Success Criteria
- [x] No implementation details leak into specification

## Notes

- This feature was scoped from a targeted codebase audit (not guesswork) confirming which
  concurrency guarantees already exist untested (ticket optimistic concurrency) versus which
  have no protection at all today (assignment double-assignment, SLA pause/resume, escalation
  idempotency) — see spec.md's own Assumptions section.
- Per this project's own roadmap convention, exact load-test pass/fail thresholds are left as an
  explicit `OPEN BUSINESS DECISION` (FR-009) rather than invented — this is intentional, not a
  gap requiring [NEEDS CLARIFICATION].
- All items pass; no revision iterations were needed.

## Implementation-time findings

- **All three suspected real races were confirmed real, then fixed.** Before the fix, firing 20
  genuinely concurrent assignment attempts at the same ticket reliably threw an unhandled
  Postgres unique-constraint error once the new `assignments_one_current_per_ticket` partial
  index was in place (proving the race existed even before the retry logic was added) — after
  the fix (bounded retry with jitter in `AssignmentRepository.createAssignment`), it holds
  consistently across 10 repeated runs. Escalation idempotency was proven the same way: the
  database-level unique-violation is visibly caught and absorbed in the logs during the test,
  confirming the fix actually engages under a genuine race rather than sitting untested.
- **The ticket-status optimistic-concurrency mechanism (User Story 4) needed no fix** — proven
  correct on the first run, exactly as research.md's Assumptions predicted.
- **A real, pre-existing test-infrastructure issue was found and resolved along the way**: the
  throwaway integration-test Postgres database had accumulated a very large number of tickets
  over this project's long development history, and the ticket-code generator's own
  documented "rare race between two concurrent creates" (a read-then-increment sequence number
  scoped by code prefix) became a frequent occurrence at that accumulated volume — manifesting
  as dozens of unrelated integration-test failures when the full suite ran, unrelated to any
  change in this feature. Confirmed by direct reproduction (a debug run showing the literal
  `Unique constraint failed on the fields: (code)` error) and by re-running the exact same
  suite cleanly (122/124 passing, matching the project's known accepted baseline) after
  dropping and recreating the throwaway database and replaying its full migration history
  (`prisma migrate deploy`, 12 migrations including this feature's own). This is a test-
  infrastructure hygiene finding, not a defect in this feature's own code.
- **Two additional integration-test failures seen only in the full-suite run (never in
  isolation)** were confirmed to be pre-existing cross-file contamination inherent to this
  suite's shared-database, non-fully-isolated hierarchy/agent scoping (already acknowledged in
  comments elsewhere in the suite, e.g. sla-escalation-flow.test.ts's own note about a
  wildcard SLA policy leaking across concurrently-running files) — re-running the two affected
  files together in isolation passed cleanly (13/13), ruling out this feature's own changes as
  the cause.
- The autocannon-based load-test tooling (User Story 5) surfaced a real, non-obvious cost
  consideration: ticket creation asynchronously triggers a real, billed Anthropic API call for
  that ticket's first AI diagnosis turn (005-ai-support) — this applies to both the
  ticket-creation and AI-support-flow load scripts, not only the latter as initially assumed.
  All three scripts were run once at a small, explicitly bounded scale (confirmed with the
  project owner beforehand) rather than an open-ended duration, specifically to keep this real
  cost small and predictable.