gitreins-async-judge-log-path-mismatch-jobid

Answer

Wrote the verified solution to:

~/gitreins-async-judge-log-path-mismatch-jobid.md

What I found

I located gitreins 0.15.0 (broken pipx symlink → installed the wheel into a venv), reproduced the bug, patched it, and re-verified.

Root cause — _cmd_judge_async in gitreins/cli.py calls new_job_id() three times for one dispatch:

log_path = job_log_path(new_job_id())   # id A → .log filename
...
job_id = new_job_id()                   # id B → --run-job / .json / header
...
job = make_job(task_id, workdir)        # make_job mints id C, overwritten by B

So the header/poll: id (B) and the log: path id (A) are unrelated UUIDs — deterministic, not a race.

Reproduced (pre-fix):

Async job dispatched: job-a61373832d2d427ab025d4b74580c265
  log:  /tmp/repro/jobs/job-fdb8afcac1114281b32ab34474315a09.log

ls showed only job-a613….json + job-fdb8….log.

Fix — mint the id once and reuse it for the log path, worker argv, and record:

job_id = new_job_id()
log_path = job_log_path(job_id)
...
job = make_job(task_id, workdir, job_id=job_id)   # optional hardening

Verified (post-fix): header, log filename, .json, and poll: all share job-f931948993b0418a8bc1257c4cab84e0, and judge --status resolves it.

The doc also bakes in the correct polling contract from the task context: poll only the dispatch-header id; read result.passed/result.verdict/result.items from jobs/job-<header-id>.json; and match .gitreins/history/.../verdict.json by task_id, never by mtime-newest alone. It includes copy-paste patches, an installed-copy patch script, a regression test, and the capture logs.