[RohithReddy20]

What & why

Fixes #8445.

connectRelay called host.ensure once per process, and a 4403 forbidden close from the relay was retried like any other drop. A host whose access row disappeared kept reconnecting every 5 s and never recovered until restart.

• On a 4403 close the tunnel client stops the retry cycle, runs host.ensure again (same 30 s to 5 min backoff as boot), then reconnects. A refusal is recorded until the next host.ensure result replaces it.
• Repeated refusals back off 30 s, 60 s, up to 5 min. The counter resets on the first control message, not on open, since the relay opens before it refuses.
• Each host.ensure attempt has a 30 s deadline so a stalled request can't block reconnects.

How I tested it

• Ran the host-service against a local stub relay and API, then dropped the host's row. On main it got 4403 on every reconnect for a minute and never called host.ensure again. With this branch it re-registered on the first 4403 and reconnected.
• Against a stub relay that refuses three times, this branch waited 0 s, 30 s, then 60 s between attempts before connecting.
• bun test src/tunnel/ in packages/host-service: new tests for the 4403 recovery against a local relay, the backoff sequence, and the ensure deadline. Each fails on main.
• Full packages/host-service suite: 2644 pass, 0 fail.
• lint, typecheck clean.

Checklist

• PR title follows conventional commits (type(scope): subject)
• bun run lint and bun run typecheck pass (CI fails on lint warnings too)
• "Allow edits from maintainers" is checked on fork PRs

Summary by CodeRabbit

• Bug Fixes
  • Improved recovery when a relay rejects a connection, with retries that back off over time.
  • Registration attempts now time out and can be cancelled during shutdown, helping prevent connections from getting stuck.
  • Relay resolution and tunnel setup no longer repeat as part of registration retries.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: f162c223-260f-46ce-af3e-66f22250af9c

Commits

Reviewing files that changed from the base of the PR and between 0f79020 and c377332.

Files selected for processing: 1

• packages/host-service/src/tunnel/tunnel-client.ts

Files skipped from review as they are similar to previous changes: 1

• packages/host-service/src/tunnel/tunnel-client.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.

Walkthrough

Host registration now retries independently of relay setup. When the relay closes a control connection with code 4403, the tunnel client can re-register the host before reconnecting, with delays for repeated refusals.

Changes: Host recovery

Layer / File(s)	Summary
Registration and relay setup packages/host-service/src/tunnel/connect.ts, packages/host-service/src/tunnel/connect.test.ts	registerHost retries registration with a 30-second per-attempt timeout and supports caller cancellation. connectRelay resolves the relay and creates the tunnel after registration succeeds. Its forbidden-close callback attempts registration again. The test covers cancellation during a pending registration attempt.
Forbidden-close recovery packages/host-service/src/tunnel/tunnel-client.ts, packages/host-service/src/tunnel/tunnel-client.test.ts, packages/host-service/src/tunnel/tunnel-client.integration.test.ts	When configured with onForbidden, the client handles code 4403 closes through the callback before reconnecting. Repeated forbidden closes use delays that start immediately and then grow from 30 seconds to a five-minute cap. Incoming control messages reset the retry count. Unit and real-socket tests cover reconnection and callback behavior.

Priority: Normal

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Bug fix · Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  participant Relay
  participant TunnelClient
  participant registerHost
  participant HostAPI
  Relay->>TunnelClient: Close control connection with code 4403
  TunnelClient->>registerHost: Invoke onForbidden with close reason
  registerHost->>HostAPI: Call host.ensure.mutate
  HostAPI-->>registerHost: Return registration result
  registerHost-->>TunnelClient: Complete recovery callback
  TunnelClient->>Relay: Reconnect control connection

Loading

Possibly related PRs

• ParadevAI/Paradev#8900: Changes the same tunnel recovery flow with forbidden-close handling, re-registration, and refusal backoff.

Merge Risk: Minimal · up to c3773

The reviewed recovery path addresses relay refusals without an established merge-blocking issue.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 22.22% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 9 functions across 5 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 4 passed

Check name	Status	Explanation
Title check		The title "fix(host-service): re-register the host when the relay refuses it" follows conventional commit format and names the primary change. The changeset adds a registerHost function and an onForbi…
Description check		The description follows the template's main sections. It covers What & why with a linked issue (fixes #8445), a How I tested it section with concrete steps and results, and a checklist. The checklist …
Linked Issues check		The changes satisfy the coding requirements in [#8445]. TunnelClient intercepts relay close code 4403, invokes recovery, and delays reconnects with the required 0, 30, 60-second sequence up to five …
Out of Scope Changes check		The reviewed changes stay within [#8445]. The production changes implement host re-registration after relay refusal, retry backoff, timeout handling, and the related tunnel behavior. The added tests v…

Full details: Title check

Explanation

The title "fix(host-service): re-register the host when the relay refuses it" follows conventional commit format and names the primary change. The changeset adds a registerHost function and an onForbidden recovery path that re-runs host.ensure after a 4403 forbidden close from the relay. The title is specific and matches the objectives of the PR.

Full details: Description check

Explanation

The description follows the template's main sections. It covers What & why with a linked issue (fixes #8445), a How I tested it section with concrete steps and results, and a checklist. The checklist items are marked as complete. The description does not include screenshots, which the template prefers for user-visible changes. This host-service change is not a UI change, so the gap is minor. The description also does not state whether the 4403 check uses the not_registered reason from the linked issue, and it does not say how failed re-registration is reported through health.check.

Full details: Linked Issues check

Explanation

The changes satisfy the coding requirements in [#8445]. TunnelClient intercepts relay close code 4403, invokes recovery, and delays reconnects with the required 0, 30, 60-second sequence up to five minutes. Recovery calls registerHost, which reruns host.ensure, uses a 30-second attempt deadline, retries with 30-second-to-five-minute backoff, and records failures for health reporting. The client resets the refusal counter after an inbound control message. Tests cover the recovery ordering, backoff, reset, and registration deadline.

Full details: Out of Scope Changes check

Explanation

The reviewed changes stay within [#8445]. The production changes implement host re-registration after relay refusal, retry backoff, timeout handling, and the related tunnel behavior. The added tests verify these behaviors. No unrelated production change is established by the supplied evidence.

Finishing Touches: 💡 1

🛠️ Fix failing CI checks: 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The changes since the previous review appear safe to merge.

Summary

The PR re-registers hosts after the relay refuses a connection.

• Hosts re-register before reconnecting after a relay refusal.
• Registration requests stop waiting after 30 seconds.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Relay closes with 4403] --> B[Pause reconnects]
  B --> C[Record registration failure]
  C --> D[Retry host.ensure until success or shutdown]
  D --> E[Wait before reconnecting after repeated refusals]
  E --> F[Reconnect to relay]
  F --> G[First control message resets refusal count]

Loading

_{Reviews (2) · Last reviewed commit: "fix(host-service): trim the relay refusa..." · Reviewed by Greptile}

[RohithReddy20]

@coderabbitai review

[RohithReddy20]

@greptileai review

[coderabbitai]

⚠️ Action not completed

Already reviewed the last commit. Use @coderabbitai full review to rerun a review of the entire changeset.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[RohithReddy20]

I have read the CLA Document and I hereby sign the CLA