<!--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> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=591309) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=591309) </details> <!--IssueSummary end--> ## Summary Whenever a checksum is performed for a project repository, update the verification checksum value in **both** `project_states` and `project_repository_states` tables, regardless of which replication version (V1 or V2) is currently active. ## Problem When toggling between V1 (project-based) and V2 (project_repository-based) replication, the verification state in the target version's table may be empty or outdated: - **V2 to V1**: newly added projects under V2 won't have `project_states` records, requiring full re-checksumming - **V1 to V2**: `project_repository_states` records don't exist yet, requiring full re-checksumming Both transitions would cause all project repositories to re-enter "pending" verification state, leading to unnecessary load on Gitaly and degraded Geo verification confidence for an extended period on large instances. ## Proposal When a checksum is calculated (in either V1 or V2 mode), write the result to both state tables. This ensures that whichever version is active, the other table stays reasonably up to date. This dual-write logic should be kept only until V1 is completely removed. ### Benefits - **V2 to V1 toggle**: eliminates re-checksumming entirely for repos that were checksummed under V2 - **V1 to V2 toggle**: for customers who stay on incremental upgrades, `project_repository_states` will be pre-populated by the time they switch to V2 - **Dedicated customers**: automatic upgrades will benefit from the bake period between the dual-write release and the V2-default release ## Implementation plan :warning: Yet to be verified by a human The right place to hook in is `verification_succeeded_with_checksum!` in `Geo::VerificationState`, which is the single point where a checksum result is written. The dual-write should be added to `ProjectRepositoryReplicator` by overriding `verification_succeeded_with_checksum!` (or a dedicated callback), so it stays scoped to this replicator and doesn't affect others. **1. Override `verification_succeeded_with_checksum!` in `ProjectRepositoryReplicator` (or its state object)** After the primary state record is saved, also upsert the checksum into the sibling table: - When the active model is `Project` (V1): find or create the `Geo::ProjectRepositoryState` for the associated `project_repository` and write the checksum and `verification_succeeded` state to it. - When the active model is `ProjectRepository` (V2): find or create the `Geo::ProjectState` for the associated `project` and write the checksum and `verification_succeeded` state to it. The upsert must be idempotent. Since [#590033](https://gitlab.com/gitlab-org/gitlab/-/work_items/590033) added a unique constraint on `project_repository_states.project_repository_id`, `upsert` with `unique_by: :project_repository_id` is now safe for `Geo::ProjectRepositoryState`. `Geo::ProjectState` already has a unique constraint on `project_id`. The sibling write should be best-effort: wrap it in a `rescue StandardError` and log the error rather than letting it bubble up and fail the primary checksum write. **2. Handle the case where the sibling record does not exist yet** - Under V1, a `project_repository` record may not exist for a given project (e.g. projects without a Git repo). In that case, skip the sibling write silently. - Under V2, a `project_state` record may not exist. Use `upsert` or `find_or_initialize_by` + `save` to create it if missing. **3. Only write `verification_succeeded` state to the sibling table** Do not mirror `verification_failed` or `verification_pending` states to the sibling table. The goal is only to keep a valid checksum available for the toggle scenario, not to fully replicate the state machine. **4. Scope the dual-write behind the FF** The sibling write should only happen while both V1 and V2 coexist. Gate it with a check: if `geo_project_repository_replication_v2` is enabled, skip the V2→V1 sibling write (it's no longer needed), and vice versa. This avoids unnecessary writes once the FF is permanently enabled. Alternatively, always dual-write regardless of the FF state, and remove the dual-write entirely when V1 is removed. This is simpler and avoids FF-gated logic inside the write path. **5. Add specs** - When a `Project` is checksummed under V1, assert that the corresponding `Geo::ProjectRepositoryState` record is created/updated with the same checksum. - When a `ProjectRepository` is checksummed under V2, assert that the corresponding `Geo::ProjectState` record is created/updated with the same checksum. - Assert that a failure in the sibling write does not fail the primary checksum write. - Assert that the sibling write is skipped when the associated record does not exist (e.g. no `project_repository` for a project without a repo). ## Context - Discussion: https://gitlab.com/gitlab-org/gitlab/-/issues/546175#note_3108512757 - Parent epic: https://gitlab.com/groups/gitlab-org/-/epics/17974 - Related: https://gitlab.com/gitlab-org/gitlab/-/issues/590033 (unique constraint prerequisite)