Repository navigation
pre-commit: detect-secrets runs in parallel batches that race on .secrets.baseline, so large commits and base merges can't commit #16343
Description
Activity
A second cause, found independently while merging base into #16273: base's own
.secrets.baselinehas stale line numbers. Later PRs shifted lines in files with baselined entries after #16300 regenerated the baseline. So any commit that stages those files, and every base merge does, gets a baseline rewrite from the hook, even after the race is fixed. For now, PR authors either take that unrelated churn or work around it by merging in the other direction (a branch off base that merges the PR, so only the PR's files are staged), which is how #16273 is handling it.Acceptance criteria added:
- The same PR refreshes
.secrets.baseline'sline_numberfields to base's current content, in one commit whose diff changes onlyline_numberfields (nohashed_secret,filename,typeoris_secretchange). That's verified by a field-level diff against base's baseline. - After it lands, a base merge into any open PR produces no
.secrets.baselinechange.
- The same PR refreshes
- added a commit that references this issue
on Sep 11, 2026 - added a commit that references this issue
on Sep 12, 2026 Closing: all 3 criteria met on
Dev_new_gui(4a7e76e28), delivered by #16349.AC Evidence 1. require_serial: trueon the hook.pre-commit-config.yaml:624-627id: detect-secretswith a comment explaining upstream sets none2. A base merge commits in one pass Mechanism fixed by AC1; the guard test below pins it structurally 3. A guard test pins it, can't drop silently repo_tests/precommit_baseline_hooks_run_serially_16343_test.py:62,72,82— presence, serial-running, and the detector's own accept/reject self-test
Problem
The
detect-secretspre-commit hook added in #16300 (.pre-commit-config.yaml:615-619) doesn't setrequire_serial: true, and neither does upstream's hook manifest (Yelp/detect-secretsv1.5.0.pre-commit-hooks.yaml:id,name,entry: detect-secrets-hook,language: python,files: .*, nothing more).pre-commit therefore runs
detect-secrets-hookin parallel batches. Each batch process reads.secrets.baseline, updates the line numbers for its files, and writes the whole file back. The writers race, the last one wins, and every other batch's updates are lost. The hook then fails with "Pleasegit add .secrets.baseline", and each retry keeps only a fraction of the needed updates.Evidence (2026-09-11)
A base merge into #16199's branch, touching hundreds of files after #16300 regenerated the baseline, failed on this hook on every commit attempt:
line_numberfields relative to base's baseline: no hashed secret, filename or type. So the rewrites were correct, just lost to the race.Fix
Add
require_serial: trueto thedetect-secretshook entry in.pre-commit-config.yaml, which overrides upstream's manifest. It's one line, and it costs a little speed on large commits.Acceptance criteria
detect-secretshook entry hasrequire_serial: true..secrets.baselinein a single pass. Show it with a base merge that commits on its first attempt after staging the baseline once.require_serial: trueon any hook that rewrites a shared file (at leastdetect-secrets), so the setting can't be dropped silently.