Resumed chunk run fails to publish, conflicting with its own merged chunk

[kimeta]

Summary

A resumed chunked run fails at publication when rebasing onto origin/master, because it
conflicts with the test files its own previously-merged chunk already put there. The workflow
ends in FAILED and the entire chunk's output is discarded.

Evidence

Issue #2183, org.springframework:spring-core:5.3.15, cycle 5 of an overnight do-work run.

Chunk 1 was published earlier in the same run and merged as PR #9597 at 2026-08-29T04:49:32Z.
Its generated tests are on master:

tests/src/org.springframework/spring-core/5.3.15/src/test/java/org_springframework/spring_core/SunReflectionFactoryInstantiatorTest.java
tests/src/org.springframework/spring-core/5.3.15/src/test/java/org_springframework/spring_core/UnsafeFactoryInstantiatorTest.java
tests/src/org.springframework/spring-core/5.3.15/src/test/java/org_springframework/spring_core/UnsafeUtilsTest.java

Cycle 5 resumed the same issue for the next chunk, produced 1966 generated lines and 156 metadata
entries, and then failed:

Recorded preimage for 'tests/src/org.springframework/spring-core/5.3.15/src/test/java/org_springframework/spring_core/SunReflectionFactoryInstantiatorTest.java'
Recorded preimage for '.../UnsafeFactoryInstantiatorTest.java'
Recorded preimage for '.../UnsafeUtilsTest.java'
Recorded preimage for '.../src/test/resources/META-INF/spring.factories'
Could not apply 6df8662574... Add Spring Core dynamic access coverage tests
ERROR: Issue #2183 finalization raised an exception: CalledProcessError(1, ['git', 'rebase', 'origin/master'])

  File "forge/git_scripts/branch_publication.py", line 338, in publish_branch
    subprocess.run(["git", "rebase", base_ref], check=True, cwd=repo_path)
subprocess.CalledProcessError: Command '['git', 'rebase', 'origin/master']' returned non-zero exit status 1.
run failed in publication/publish_branch()[org.springframework:spring-core:5.3.15]
ERROR: finalization failure

======================================== FAILED ========================================
Issue #2183: Support for org.springframework:spring-core:5.3.15
Workflow failed; failure follow-up was attempted.

Every file named in the conflict is one chunk 1 created and merged.

Cause

The resumed run branches from a checkout that predates the merge of its own chunk-1 pull request,
so it regenerates the same test files from a base where they do not exist. Rebasing that branch
onto origin/master — where those files now exist with different content — conflicts on each one,
and git rebase is invoked with check=True, so the failure aborts publication.

This shares a root with #9612: the worker's checkout is behind master. There it makes a chunked
issue's exhaust report invisible; here it makes the chunk's own predecessor a merge conflict.

Impact

The chunk's entire output is lost. This run spent roughly an hour on it — including a full
40-cycle native trace budget, see #9608 — and produced nothing, while the issue is left claimed
and the workflow reports FAILED.

The failure is also self-perpetuating: every chunk that merges makes the next resume from a stale
base more likely to conflict, so a chunked library becomes progressively harder to advance the
more progress it makes.

Suggested handling

1. Update the checkout to current origin/master before starting a resumed chunk, so the run
   regenerates against what is already published rather than against a stale base.
2. Do not let a rebase conflict discard completed work. Publication is the last step; the metadata
   and tests are already verified by that point, and the branch could be re-cut from current
   master and reapplied instead of aborting.
3. Treat the conflicting-file set as a signal: when every conflicting path belongs to the same
   coordinate the run is working on, the correct resolution is to take the resumed run's version,
   since it was produced against the newer dynamic-access report.

[kimeta]

The salvage path fails the same way, so the preserved work is discarded too.

After the publication failure above, the run preserved the chunk's work on a branch and pushed it:

ai/kimeta/human-intervention/issue-2183-library-new-request-org.springframework-spring-core-5.3.15-c6a98283  ->  eda603395541cb66f4a13648bce6068438919fce

On the next cycle, recovering that branch failed for the same reason:

ERROR: Could not rebase preserved branch ai/kimeta/human-intervention/issue-2183-library-new-request-org.springframework-spring-core-5.3.15-c6a98283 onto master; falling back to a clean run.

The run then re-claimed #2183 and re-entered PHASE: SETUP from scratch. So the sequence for one chunk is:

1. roughly an hour of generation, including a full 40-cycle native trace budget (Native trace fallback discovers one metadata entry per image build #9608)
2. publication aborts on a rebase conflict with its own merged chunk
3. the work is preserved on a branch
4. the preserved branch cannot be rebased either
5. the run starts over clean, and the preserved branch remains on origin

Step 4 matters because the preservation branch is the designed mitigation for step 2. When the cause is a stale base, both the publish and the salvage hit it, so there is no recovery path and the work is lost twice.

For context on accumulation, origin currently holds 141 branches under ai/kimeta/human-intervention/. Not all of those come from this failure mode — the prefix is also used for work legitimately awaiting a human — but the branch above shows that a branch created purely by this path is left behind with no route back.

[kimeta]

Correction on severity: the clean-run fallback does recover.

After the preserved branch failed to rebase, the run re-generated #2183 from scratch and this time published successfully, reaching local-review against a current base:

[local-review] Reviewing org.springframework:spring-core:5.3.15 at e5f57b811c54 against 2634243ad532 with gpt-5.6-terra

So this is not a permanent block. The clean run is cut from current master, which is exactly the condition the failing run lacked, and it publishes normally.

That revises the impact stated above. The accurate cost is:

• one chunk's output discarded — roughly an hour, including a full 40-cycle native trace budget (Native trace fallback discovers one metadata entry per image build #9608)
• one orphaned human-intervention branch left on origin
• the chunk regenerated from scratch on the following cycle, succeeding

The work is lost, not the library. The severity is wasted time and an orphaned branch per occurrence, not an unrecoverable issue — and the recovery confirms the diagnosis, since the only thing that changed between the failing and succeeding attempts was the freshness of the base. Suggestion 1 above (update the checkout to current origin/master before starting a resumed chunk) would remove the failure rather than recovering from it, and would keep the discarded hour.