From d08fb4af4d8b139a0ab78dc66ec4749fd2220db0 Mon Sep 17 00:00:00 2001 From: Lucio Lelii Date: Sat, 25 Jul 2026 14:06:38 +0200 Subject: [PATCH] test: evict finished executions from the in-memory cache more aggressively ExecutionsService's ExecutionObject cache only calls shutdown() (which tears down that execution's dedicated Executors.newFixedThreadPool) on eviction, gated by app.executions.cache.max-size (default 1000) and app.executions.cache.final-ttl-ms (default 30 minutes). The Spring test context - and its singleton ExecutionsService - is reused across the whole suite, and a full run finishes in well under 30 minutes with far fewer than 1000 executions, so none of that cleanup ever fires: every execution's thread pool stays alive simultaneously for the rest of the run. That's a plausible contributor to the loop-container tests occasionally missing their polling deadline under full-suite load (they pass reliably in isolation, where far fewer executions accumulate). Lowering both knobs for tests only keeps the live thread-pool count small throughout a run; eviction only ever targets already-finished executions (see evictIfNeeded/evictFinalStateByTtl), so this cannot disrupt an in-flight test. --- src/test/resources/test.properties | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/test/resources/test.properties b/src/test/resources/test.properties index d725c6f..2da7559 100644 --- a/src/test/resources/test.properties +++ b/src/test/resources/test.properties @@ -20,3 +20,15 @@ app.assistant.provider-retry-max-delay-ms=2 app.import.path=src/test/resources/workflow-editor-init app.import.enabled=true + +# The Spring test context (and its singleton ExecutionsService) is reused across the whole +# suite. Each execution gets its own dedicated Executors.newFixedThreadPool that only gets +# shut down on cache eviction (see ExecutionsService.evictIfNeeded/evictFinalStateByTtl) - +# with the production default of 1000 and a 30-minute TTL, a full test run (hundreds of +# executions, none older than 30 minutes) never evicts anything, so hundreds of finished-but- +# not-shut-down thread pools stay alive simultaneously. That OS-level thread contention is the +# most likely cause of the loop-container tests occasionally missing their polling deadline +# under full-suite load (they pass reliably in isolation). Evicting aggressively in tests keeps +# the live thread-pool count small throughout the run. +app.executions.cache.max-size=50 +app.executions.cache.final-ttl-ms=2000