Steven Hartland

Thanks @mdelapenya, to confirm you're happy to just make the `ContainerCustomizer.Customize` return an `error`, no need to have the compatibility workaround?

I had an hour, so went ahead with what I assumed from your comment https://github.com/testcontainers/testcontainers-go/pull/2267 is now up for review. Wasn't sure if there was some where else this type...

While most options for configuring the request will be error free, there are definitely cases that can and in fact already do trigger an error. These errors need to be...

Some examples of failures that are currently hidden or result in a panic are WithNewNetwork and Neo4j, Clickhouse options. Given Customize is the only way consumers can mutate the request...

Thanks @mdelapenya happy to help, see you have some comments on the draft PR already. Where would you like to centralise the conversation about the implementation, should that be here...

[PR](https://github.com/testcontainers/moby-ryuk/pull/121) is now open against [moby-ryuk](https://github.com/testcontainers/moby-ryuk/) which fixes the underlying issue which is that the reaper container doesn't reset it's waiting for connection timeout, which means it will randomly shutdown...

Testing locally I can now run 100 iterations without fail, where as previously 10 was usually enough to trigger an issue. ```shell go test -run=TestGenericReusableContainerInSubprocess -count=100 -v -failfast ```

No problem @mdelapenya just been tripping over issues trying to get a clean test run, so now have a few PR's in flight. Looks like someone authorised the test run...

Should we re-open until we have a release and PR to bump the container version?

@mdelapenya not sure if you intended to close this with the PR against a fork of moby-ryuk?