track_id Reused Across Fixtures Causes False Test Collisions

[soumyaranjan77-web]

@Devnil434 Where:

• SUSPICIOUS_RESULT uses track_id=3 — and downstream fixtures will likely reuse low integers like 1, 2, 3 by default convention.

What's wrong:

• Phase 5 alert endpoints likely key deduplication logic, alert suppression, or DB upserts on track_id. If NORMAL_RESULT or LOW_CONF_RESULT accidentally share the same track_id as SUSPICIOUS_RESULT, tests that assert "no alert for this track" will collide with state left by a previous test. This is a fixture isolation failure — not a model validation error, but a cross-test state contamination bug that only manifests when tests run in sequence, not in isolation.

Fix:

• python# Use semantically spaced, non-colliding IDs across all 4 fixtures
• SUSPICIOUS_RESULT → track_id = 101
• NORMAL_RESULT → track_id = 202
• LOW_CONF_RESULT → track_id = 303
• EMPTY_CAPTIONS_RESULT → track_id = 404