Draft: Forward MVCC pin from /internal/allowed back to Gitaly

Stan Hurequested to merge
sh-gitaly-mvcc into master

What does this MR do and why?

Forward MVCC pin from /internal/allowed back to Gitaly

Gitaly's MVCC backend handles writes by uploading staged artifacts to durable storage and then running an inspection step before CAS-advancing the manifest pointer. The inspection step calls /internal/allowed to defer to Rails for access checks. Anything Rails does in turn against Gitaly during that callback (rev-list of the new commits, branch-protection diff walks, …) must resolve OIDs against the staged state, not the durable base — otherwise the brand-new commits look like "bad object" to the inspector and every push validation fails with HTTP 500.

Plumb the staged state through the same SafeRequestStore + gRPC metadata path that quarantine env vars already use:

  • Allowlist GIT_MVCC_MANIFEST and GIT_MVCC_STAGING_DIRECTORY in HookEnv so they survive being filtered out of the env hash Gitaly posts to /internal/allowed.

  • Stash them globally on the request (one in-flight write per request, so no per-gl_repository keying needed) and expose HookEnv.mvcc_manifest / .mvcc_staging_directory.

  • GitalyClient injects them as x-gitaly-mvcc-manifest and x-gitaly-mvcc-staging-directory headers on outbound gRPC calls when present. Header names match what Gitaly's mvcc package extracts on the server side; no Gitaly-side changes needed once Gitaly's hook manager forwards the env vars in /internal/allowed.

No behaviour change for non-MVCC repositories: when the env vars are absent, HookEnv.mvcc_* returns nil and no header is attached.

References

Screenshots or screen recordings

Before After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports