Skip to content

[QUALITY-1958] Use unique temp files when writing git credential stores - #16653

Draft
ericli-warp wants to merge 1 commit into
masterfrom
eric/quality-1958-git-credentials-unique-temp-files
Draft

ericli-warp wants to merge 1 commit into
masterfrom
eric/quality-1958-git-credentials-unique-temp-files

Conversation

@ericli-warp

Copy link
Copy Markdown

Description

Fixes intermittent Skill resolution failed: Failed to write git credentials before skill resolution: Failed to rename …/hosts.yml.tmp to …/hosts.yml: No such file or directory when several Oz runs start at the same time on one direct-backend worker host. Those runs share HOME and the gh config directory. The .git-credentials, gh hosts.yml, and glab config.yml writers each used a fixed temp name, so one run could rename another run's temp file away before that run's own rename.

Each write now goes through replace_secret_file: it creates a uniquely named 0600 temp file in the target directory, fsyncs it, and persists it over the target. write_azure_cli_token already used this pattern, so it now calls the helper too. File contents are unchanged. Docker, Kubernetes, and Namespace tasks have their own filesystems and never hit the race.

Side effects of the change:

  • git, gh, and glab writes now fsync before the rename. Only the Azure token write did this before.
  • The temp file is created exclusively, so it no longer follows a symlink placed at a predictable *.tmp path.
  • A run killed mid-write can leave a .hosts.yml.tmp-XXXXXX file behind. Normal error paths delete it.
  • The error text changes from "Failed to rename X to Y" to "Failed to replace Y".

Out of scope: .git-credentials is still read, merged, and written. Concurrent runs that receive different host sets can still overwrite each other's entries (last writer wins). Runs that receive the same hosts, such as benchmark trials for one factory, are unaffected.

I found this while running Factory benchmark trials on the oz-local direct backend. In the driver log, several trials wrote credentials within the same second and one of them failed.

Linked Issue

QUALITY-1958

  • The linked issue is labeled ready-to-spec or ready-to-implement. (Linear ticket, not a GitHub issue.)
  • Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes). (No UI change.)

Testing

  • New regression test concurrent_credential_store_writes_share_directories_safely runs 8 threads that each write all three stores into one shared home directory 25 times. It failed against the previous code with the same rename error, and it passes with this change.

  • The gh and glab filename tests now assert that the config directory contains only the target file, which catches a leftover temp file of any name.

  • cargo nextest run -p warp -E 'test(/git_credentials::tests::/)': 42 passed. cargo clippy -p warp --all-targets --tests -- -D warnings: clean. Both ran on macOS only.

  • I have manually tested my changes locally with ./script/run (not run end to end. The end-to-end check is a multi-trial benchmark run on the oz-local direct backend with a rebuilt binary.)

Agent Mode

  • Warp Agent Mode - This PR was created via Warp's AI Agent Mode

Conversation: https://staging.warp.dev/conversation/0415f6a5-02e4-471c-8710-6942fcdbd340

CHANGELOG-BUG-FIX: Fixed Oz runs on self-hosted direct-backend workers sometimes failing at startup with "Failed to write git credentials" when several runs start at the same time.

Concurrent runs on one direct-backend worker host share HOME and the gh
config directory. The .git-credentials, gh hosts.yml, and glab config
writers each used a fixed temp name, so one run could rename another
run's temp file away and fail with "No such file or directory". Write
through a uniquely named temp file instead, reusing the pattern the Azure
token writer already used.

Co-Authored-By: Warp <agent@warp.dev>
@cla-bot cla-bot Bot added the cla-signed label Oct 27, 2026
@warp-local-for-testing-only

Copy link
Copy Markdown

@ericli-warp, your GitHub account is not connected to Warp. Connect your GitHub account.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant