fix(tests): raise the GreenMail startup timeout to 120s#6229
Conversation
CsvimIdentityRestartIT failed its ApplicationContext load on the integration-tests-h2 leg (run 29081191825): GreenMail missed its 30s startup window on a loaded runner - the test boots a fresh context (restart semantics), so it pays a cold GreenMail start on a new random port. Not DB-related; the same test passed on the PostgreSQL leg. The timeout is an await, so a healthy start is unaffected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
delchev
force-pushed
the
fix/greenmail-startup-timeout
branch
from
7070535 to
d4be392
Compare
…eout was never the problem The CI failure on this PR proved the diagnosis wrong: even with 120s GreenMail still could not start. The startup timeout is only consumed when the BIND failed - and waiting longer on a port someone else holds can never succeed. The real defect: the port was probed once per JVM at class-init (static field), while the IT suite boots many Spring contexts in that JVM, each starting a fresh GreenMail on that SAME port - one lingering socket from the previous context (or any service grabbing the number in between) and every subsequent bind is dead on arrival, however long the timeout. provideGreenMailServer now probes a fresh random port immediately before each bind, retrying up to 5 times, and publishes the ACTUAL bound port into DirigibleConfig (the mail service reads it at send time, long after the context boots, so the static pre-configuration no longer needs to guess it). Timeout back to a moderate 20s - a healthy bind confirms in milliseconds. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The smoke-tests failure on this run disproved the timeout diagnosis: GreenMail failed to start even with 120s ( The real defect: Pushed the structural fix to this branch: fresh random port probed immediately before each bind, up to 5 attempts, actual bound port published into |
1 participant
The integration-tests-h2 leg of run 29081191825 failed only in
CsvimIdentityRestartIT- and not in its logic: the Spring context load failed because GreenMail missed its 30s startup window on a loaded runner (Could not start mail server smtp:localhost:36481). The test boots a fresh application context (restart semantics), so it pays a cold GreenMail start on a new random port, 90 minutes into the leg. The PostgreSQL leg ran the same test green - the failure is runner load, not H2.Raising the startup timeout to 120s; it is an await, so healthy startups are unaffected.
🤖 Generated with Claude Code