Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

First initialized solution event shares the working solution with the consumer thread (ConcurrentModificationException)

Chiusa
  • Qualcosa non va?
#2,728 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@zepfred ci sta già lavorando.

Dal 6/10/2026.

  • #2732 di @zepfred — aperta

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

Describe the bug

The first initialized solution event gives the consumer the live working solution, not a planning clone. The consumer reads it on the consumer thread, while the solver thread continues to change the same object.

Mechanism (line numbers on main at 9de70fcf and on v2.7.0):

  1. DefaultSolverJob.FirstInitializedSolutionPhaseLifecycleListener.phaseEnded (line 424) calls consumerSupport.consumeFirstInitializedSolution(phaseScope.getWorkingSolution(), ...) without a clone. The best solution and final best solution events receive clones.
  2. ConsumerSupport runs the consumer asynchronously on its consumer thread.
  3. On the solver thread, AbstractPhase.phaseEnded fires the phase listeners (line 136). Then, if assertPhaseScoreFromScratch is true (every asserted environment mode, including the default PHASE_ASSERT), it asserts the score from scratch on the same working solution (lines 137-144).
  4. The assertion calls uncorruptedScoreDirector.setWorkingSolution(workingSolution). This goes to BasicVariableState.resetWorkingSolution, which clears every @InverseRelationShadowVariable collection and fills it again.
  5. A consumer that iterates such a collection at that moment gets a ConcurrentModificationException. A consumer that does not fail can read a half-filled collection.

The event fires only when another phase follows the construction heuristic. In our tests, local search did not change the consumed solution (more than 200,000 steps with NO_ASSERT). Only the assertion from scratch did.

Expected behavior

The solution in FirstInitializedSolutionEvent does not change while the consumer reads it, as with NewBestSolutionEvent and FinalBestSolutionEvent.

Actual behavior

With PHASE_ASSERT (the default) or FULL_ASSERT, the inverse relation shadow collections of the consumed solution are cleared and filled again while the consumer reads them. The consumer gets a ConcurrentModificationException.

In the Timefold service SDK, SolverWorker.notifyOnInit converts this solution to the model output on the consumer thread. A model whose ModelConvertor.toModelOutput reads an inverse relation shadow collection fails at random with Unable to create model output for dataset with id ... (caused by ConcurrentModificationException), and the dataset ends in SOLVING_FAILED. We saw this in about one of three runs of a packaged Quarkus integration test (test profile, FULL_ASSERT).

To Reproduce

Reproducer: a test in SolverManagerTest on branch larsbeck/timefold-solver:reproducer/first-initialized-solution-race (commit e449eb41). It uses the existing TestdataInverseRelation* test domain.

mvn -pl core -am test -Dtest='SolverManagerTest#firstInitializedSolutionDoesNotChangeWhileTheConsumerReadsIt' -Dsurefire.failIfNoSpecifiedTests=false
Environment mode Result
PHASE_ASSERT (the default) Fails with ConcurrentModificationException (4 of 4 runs)
NO_ASSERT Passes

The consumer gets an iterator on every inverse relation collection, waits 500 ms, and then iterates them. The problem has 50 values and 2,000 entities, so that the assertion from scratch takes longer than the start of the consumer thread. With a small problem, the failure occurs only at random.

Environment

Timefold Solver Version or Git ref: 2.7.0 and main (9de70fcf)

Output of java -version: openjdk version "25.0.2" 2026-01-20 LTS (Temurin-25.0.2+10)

Output of uname -a or ver: Darwin 25.6.0 arm64

Additional information

  • Possible fix (not tested): send a planning clone in the event, for example phaseScope.getScoreDirector().cloneSolution(phaseScope.getWorkingSolution()), as the best solution events already do.
  • No merged pull request after the 2.7.0 release addresses this. #1583 ("clone the solution before sending it to the consumer") changed only the best solution events and was reverted in #1648.
Lingua principale
Java
Stelle
1.8k
Fork
238
Merge medio
3g 1h
PR unite (30g)
55

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di TimefoldAI/timefold-solver

Tutte le issue di TimefoldAI/timefold-solver

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.