Roman Melnikov
Roman Melnikov
> With an increased memory limit for the client vm, running the test takes a reasonable time (and the test succeeds). Sounds like a good enough way to resolve the...
The new approach seems good 👍
For reference, here are response headers from the page that is causing this error ``` $ curl -I HTTP/2 200 date: Wed, 31 Jan 2024 11:13:28 GMT content-type: text/html; charset=utf-8...
> That part of the change can be undone easily, no? Yeah, but I considered avoiding `Text -> IP -> Text -> IP` conversions. Additionally, for `waitForHttp` the manager expects...
> Did you research how Java, Ruby and Go testcontainers approach the problem? `testcontainers-go` has a similar issue, but it was closed, see https://github.com/testcontainers/testcontainers-go/issues/551. They suggest exposing the port via...
> They suggest exposing the port via IPv4 `0.0.0.0` explicitly I also have a branch with changes that allow exposing a container port on a specific host IP, see https://github.com/serokell/testcontainers-hs/commit/5d5ca97ea2f2a913e8a21e59db040b911a058b6d....
> Yeah, but I considered avoiding `Text -> IP -> Text -> IP` conversions OTOH, it's quite hard to avoid them, we do `Text -> IP -> Text` anyway
Yeah, sure, no hurry. At the moment I'm ok with using `testcontainers-hs` from the fork
I've looked at the code a bit more, and looks like the right way to solve the problem is to resolve [this TODO](https://github.com/testcontainers/testcontainers-hs/blob/master/src/TestContainers/Docker.hs#L1209)
So the actual problem is that `localhost` is resolved to `[::1]` by `head getAddrInfo ...`, while the first entry in the container port binding is IPv4, thus an attempt to...