fallintoplace opened a new issue, #1420:
URL: https://github.com/apache/iceberg-go/issues/1420

   ### Apache Iceberg version
   
   None
   
   ### Please describe the bug 🐞
   
   Hi! I noticed a flaky failure in the Go integration workflow where the Spark 
3.5 setup job sometimes fails before the actual Go integration tests start.
   
   The failing job is:
   
   integration-test (3.5, integration-setup)
   
   Example failed runs:
   
   https://github.com/apache/iceberg-go/actions/runs/28865791807
   
   https://github.com/apache/iceberg-go/actions/runs/28865731963
   
   The failure happens during the integration setup step, while running:
   
   make integration-setup
   
   That target runs Docker Compose with:
   
   docker compose -f internal/recipe/docker-compose.yml up -d --wait
   
   The setup fails with:
   
   container trino is unhealthy
   
   From the logs, this looks timing-related. In one failed run, Docker Compose 
marked Trino as unhealthy, but Trino finished starting almost immediately 
afterward and logged:
   
   Server startup completed in 30.09s
   
   ======== SERVER STARTED ========
   
   So it seems like Trino is still coming up, but Docker Compose gives up just 
before it becomes ready.
   
   This does not look related to the Go code change that triggered the run, 
since the failure happens during Docker setup before the integration tests are 
executed. The Spark 4.0 integration job also passed in the same workflow run, 
and nearby CI runs have passed, which makes this look like a flaky 
setup/readiness issue rather than a deterministic test failure.
   
   Expected behavior
   
   The integration setup should wait long enough for Trino to become ready, or 
use a readiness check that avoids failing when Trino is just slow to start.
   
   Possible fixes
   
   A few possible ways to make this more stable:
   
   Increase Trino’s healthcheck/startup budget.
   
   Add an explicit healthcheck/start period for the Trino service.
   
   Pin the trinodb/trino image to a known stable version instead of using the 
floating latest image.
   
   Add a small retry around the Docker Compose setup step if this is expected 
to occasionally race.
   
   Additional context
   
   The Trino service in internal/recipe/docker-compose.yml currently uses 
trinodb/trino, and the failure appears to be caused by service readiness timing 
rather than a failing Go integration test.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to