thread 'DNS worker' panicked about mirrord HOT 12 CLOSED

Thanks for reporting this - Are you using the operator?
I suspect that the remote pod you're targeting had a restart, which leads to mirrord failing to access it's Linux namespace.
Can you verify if the container you target had a restart? Sometimes this happens due to health checks failing (timeout) so we recommend using a HTTP filter to avoid stealing the health checks.

from mirrord.

hi,
that is correct, we are not using the operator for now and the pod restarts. it does not usually restart when mirrored it is not being executed. what should I do?
thank you in advance

from mirrord.

thanks for the clarification - this means you're using mirrord OSS and not enterprise :)

Can you check what's the reason for the restart?

from mirrord.

The pod exits with code 0 and status completed which is weird, I am trying this with another service and it works perfectly without issues

from mirrord.

I mean the reason for the restart of the target pod - your service.
P.S if you'd like we can do a screenshare session to debug it.

from mirrord.

after the mirrord connection, I am seeing this:
│ app {"level":40,"time":1716896956775,"msg":"[app] [http] SIGTERM received stopping server..."} │

from mirrord.

I would like you to describe the app's pod, and see if there's any kubernetes event saying restart / health check failed etc

from mirrord.

yeah I see this:

What I did not understand is why the other service works perfectly and not this one. Both have the same checks

from mirrord.

You can probably run the application with a debugger - put a breakpoint into health and see where it hangs
Also - do they have the same timeouts?

from mirrord.

No, locally acts in the same way as the service that is working, it logs the endpoint call:

from mirrord.

Would you like to debug it over a call?

from mirrord.

Issue was health checks being stolen and not answered in a timely manner.

from mirrord.