Vulnerability UUID Migration Phase 4: Transition GitLab to use new_uuid
<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=587804) </details> <!--IssueSummary end--> ## Problem After `new_uuid` is fully populated and has a NOT NULL constraint, we need to transition all GitLab code to use `new_uuid` instead of the old `uuid` column for vulnerabilities. ## Implementation 1. Audit all code paths that reference `vulnerabilities.uuid` 2. Update code to read from `new_uuid` instead of `uuid` 3. Update any indexes, foreign keys, or constraints that reference `uuid` 4. Feature flag the transition for safe rollout 5. Update API responses and GraphQL schemas as needed 6. Ensure backward compatibility during transition period ## Acceptance Criteria - [ ] All code paths updated to use `new_uuid` - [ ] Feature flagged for safe rollout - [ ] API/GraphQL compatibility maintained - [ ] No regressions in functionality ## Dependencies - Blocked by Phase 3 (NOT NULL constraint must be in place) ## Related - Part of Vulnerability UUID migration series - #587624 - Phase 1: Start populating new_uuid
issue