Fix: make Competitive Companion listener robust on IPv4/IPv6 localhost

[znzryb]

To fix #155.

Summary

• Fix intermittent failures when receiving problems from Competitive Companion on macOS where localhost may resolve to IPv6 (::1) first.
• Bind the listener to both IPv4 and IPv6 loopback addresses when possible, so requests to http://localhost:<port>/ are handled reliably.

Test executed

• On macOS, open CLion with AutoCp enabled.
• Click Competitive Companion “+” on a problem page and verify AutoCp receives the problem and starts the generation workflow.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 0% with 73 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...github/pushpavel/autocp/gather/base/localServer.kt	0.00%	60 Missing ⚠️
...pavel/autocp/gather/base/ProblemGatheringBridge.kt	0.00%	13 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Files with missing lines	Coverage Δ
...pavel/autocp/gather/base/ProblemGatheringBridge.kt	0.00% <0.00%> (ø)
...github/pushpavel/autocp/gather/base/localServer.kt	0.00% <0.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Pushpavel]

Hi @znzryb, its ok if we bind to both interfaces on different ports (127.0.0.1:8000, ::1:9999). competitive companion is going to send request for both the ports anyway. With that, the code change should be pretty simple, our server should accept a InetAddress argument and we should run two servers.

• Improve request handling by reading the HTTP body without relying on EOF and returning a minimal 200 OK response to avoid hanging connections.

I don't understand the problem here. but if its really an issue, Its better we switch to an http server library like ktor than maintaining complicated parsing logic.

[znzryb]

Hi @znzryb, its ok if we bind to both interfaces on different ports (127.0.0.1:8000, ::1:9999). competitive companion is going to send request for both the ports anyway. With that, the code change should be pretty simple, our server should accept a InetAddress argument and we should run two servers.

• Improve request handling by reading the HTTP body without relying on EOF and returning a minimal 200 OK response to avoid hanging connections.

I don't understand the problem here. but if its really an issue, Its better we switch to an http server library like ktor than maintaining complicated parsing logic.

okay, I will delete these logics, It's not really an issue.

[znzryb]

Hi @znzryb, its ok if we bind to both interfaces on different ports (127.0.0.1:8000, ::1:9999). competitive companion is going to send request for both the ports anyway. With that, the code change should be pretty simple, our server should accept a InetAddress argument and we should run two servers.

• Improve request handling by reading the HTTP body without relying on EOF and returning a minimal 200 OK response to avoid hanging connections.

I don't understand the problem here. but if its really an issue, Its better we switch to an http server library like ktor than maintaining complicated parsing logic.

okay, I already delete codes of http 200 "ok" code reply. Also, I test it, it can run in complex environment like below too.

zzy@Mac ~ % lsof -nP -iTCP:27121 -sTCP:LISTEN
COMMAND    PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
Code\x20H 4074  zzy   50u  IPv6 0x42979cd2fe18d20f      0t0  TCP *:27121 (LISTEN)
clion     7887  zzy   28u  IPv6 0xff5097da8ac17a2a      0t0  TCP 127.0.0.1:27121 (LISTEN)
clion     7887  zzy   45u  IPv6  0x53b624cd3bdddd1      0t0  TCP [::1]:27121 (LISTEN)
zzy@Mac ~ %

[Pushpavel]

Hi @znzryb, I've reviewed the changes again. readHttpBody is still present, and handling the two sockets manually inside the bridge is adding quite a bit of complexity.

I would prefer we go with the simpler approach:

1. Extract the server logic into its own simple class (the logic in ProblemGatheringBridge)
2. In ProblemGatheringBridge, create two separate instances of that class (one bound to 127.0.0.1 and one to ::1).
3. Handle the start, stop, and dispose lifecycle for both instances there.

This will be much easier to maintain than managing two raw sockets directly.

There's no rush on this, so take your time, Let me know if you have any questions.

[Pushpavel]

Hey @znzryb, ignore the last comment, If it works that's all that matters. I will merge this.