Update ryuk#72
Open
nikita-volkov wants to merge 12 commits into
Open
Conversation
Since GitHub Actions now support it
- Replace waitUntilMappedPortReachable for ryuk with waitForLogLine on ryuk's "Started" log message. A TCP probe to ryuk's protocol port registers as a client that immediately disconnects without labels; ryuk 0.14.0 treats this as a completed session and exits (1 ns reconnection timeout when no resources are registered), causing the subsequent real connection from newRyukReaper to get ECONNRESET. - Simplify rabbitmq readiness to waitUntilMappedPortReachable 5672. RabbitMQ 3.13 changed its startup log format and no longer outputs the "completed with" line that the previous wait condition relied on. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Root cause: After ryuk logs "Started", Docker Desktop/Colima on macOS has a small delay before the VM-to-host port forwarding becomes active. The original newRyukReaper made one immediate Socket.connect with no retry, so it hit ECONNREFUSED on macOS even though ryuk was actually running. Using waitUntilMappedPortReachable as the wait strategy isn't an option (it probe-connects and immediately disconnects, which ryuk 0.14.0 treats as a completed session causing it to exit). Fix: Added a connectWithRetry 60 loop inside newRyukReaper — up to 60 attempts with 500 ms delay between them (30 s total budget), catching IOException specifically on each attempt and closing the failed socket before retrying with a fresh one. This mirrors the retry pattern already used by waitUntilMappedPortReachable and waitForHttp, without triggering ryuk's session-termination logic.
LaurentRDC
reviewed
Jun 14, 2026
Collaborator
|
What would be required to enable tests on Windows? |
alexbiehl
approved these changes
Jun 14, 2026
nikita-volkov
force-pushed
the
update-ryuk/1
branch
from
24c4662 to
26f2b02
Compare
Root cause: waitUntilMappedPortReachable 5672 is unreliable on macOS because port-forwarding through Lima's SSH tunnel can cause Socket.connect to block indefinitely (hanging rather than returning ECONNREFUSED). The System.Timeout.timeout can't always interrupt a blocking FFI syscall in time, so the 60-second default timeout doesn't reliably fire.
Fix: Switch back to waitForLogLine Stdout ("started TCP listener" LazyText.isInfixOf). RabbitMQ 3.13 logs "started TCP listener on [::]:5672" the moment it binds the AMQP port — this doesn't involve host port-forwarding at all (it reads from docker logs --follow inside the container), so it's immune to macOS networking quirks. The original log-based approach ("completed with") broke when RabbitMQ 3.13 changed its startup log format; "started TCP listener" is the correct replacement.
- configDefaultWaitTimeout was applied as an outer cap in waitUntilReady, silently overriding any explicit waitUntilTimeout the caller provided. Fix: skip the default when the input is already a WaitUntilTimeout so that explicit timeouts take precedence. - RabbitMQ readiness: switch from waitUntilMappedPortReachable (flaky on macOS because Socket.connect through Lima's SSH tunnel can block rather than returning ECONNREFUSED) to waitForLogLine Stdout on "started TCP listener", wrapped with waitUntilTimeout 300. The macOS CI runner (Intel/QEMU, 3.8 GB RAM) needs well over 60 s to boot RabbitMQ; the log-based strategy avoids host port-forwarding entirely and the explicit 300 s timeout now works as intended after the semantics fix above.
On macOS/Lima, DNS lookups inside the VM can time out transiently, causing docker pull to fail with an i/o timeout. Retry up to 3 times with a 2 s delay before propagating the exception.
LaurentRDC
approved these changes
Jun 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The changes in this PR are done with the use of AI. Following is the summary:
"Started"log line; added socket connection retries to handle port-forwarding lag on macOS/Docker Desktop\\.\pipe\docker_engine) instead of a Unix socket when the Docker daemon is running Windows containersubuntu-24.04-arm,macos-26-intel, andwindows-latest; GHC versions trimmed to9.2and9.12; tests skipped on Windows (no Linux Docker daemon) but the build still runs to verify compilationactions/checkoutto v6 and ormolu to 0.8.1.0