tcjlj/flvx
1
0
Fork 0
mirror of https://github.com/Sagit-chu/flvx.git synced 2026-10-06 18:06:36 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
31977a62e65db2ca58274c5252fbfe16f81ae24d
flvx/plans/016-tunnel-runtime-bind-conflict-retry.md
T
sagitchu 87479c2ac1 fix: add retry mechanism for tunnel service bind conflicts 
When tunnel services encounter 'address already in use' errors during
creation/update, automatically cleanup and retry once instead of failing
immediately. This handles race conditions during rapid tunnel reconfiguration.

Entire-Checkpoint: 39e6fb9de836
2026-03-07 16:21:44 +08:00

2.0 KiB
Raw Blame History

016 Tunnel Runtime Bind Conflict Retry

Checklist

  • Confirm tunnel connectIp precedence remains connectIp > node tcp_listen_addr for runtime service listen address.
  • Add tunnel runtime address already in use recovery that deletes the stale service and retries AddService.
  • Keep non-bind failures unchanged and avoid altering tunnel chain apply semantics.
  • Add regression tests for tunnel service address precedence and bind-conflict retry behavior.
  • Run focused backend handler tests and record the result.
  • Add a contract test that simulates node-side address already in use during tunnel update and verifies retry success.
  • Investigate whether forward update address already in use reports are only tunnel-redeploy linkage or also an independent forward path.
  • Add a contract test that simulates node-side address already in use during tunnel update and verifies retry success.
  • Investigate whether forward update address already in use reports are only tunnel-redeploy linkage or also an independent forward path.

Test Record

  • Command: cd go-backend && go test ./internal/http/handler/...
  • Result: passed.
  • Command: cd go-backend && go test ./tests/contract/... -run 'TestTunnelUpdateRecoversFromAddressInUseContract|TestForwardCreateRollbackWhenServiceDispatchReturnsAddressInUseContract|TestForwardUpdateIgnoresDeletedSpeedLimitContract'
  • Result: passed.
  • Command: cd go-backend && go test ./tests/contract/... -run 'TestForwardUpdateRecoversFromAddressInUseContract|TestTunnelUpdateRecoversFromAddressInUseContract'
  • Result: passed.

Investigation Note

  • Forward update still has its own independent address already in use recovery path in syncForwardServicesWithWarnings / rebindForwardServiceOnSelfOccupiedPort; tunnel update linkage is not the only possible source of the symptom.
  • Tunnel update also triggers downstream forward UpdateService for bound forwards, so users can still observe the same error around a tunnel edit even when the failing runtime is on the tunnel side.
Reference in New Issue View Git Blame Copy Permalink