[ogulcancelik]

refs #4601

A single failed accept on the API socket (ECONNABORTED on macOS, EMFILE, etc.) broke the listener loop for good. The server and panes kept running, but every CLI command, live handoff, and herdr session stop failed with server_not_running until the server was killed.

The accept loop now logs the error, backs off 50ms, and keeps accepting. It only exits on error during shutdown. Repeated failures log once at error level and once on recovery, so a sustained failure doesn't flood the log.

Verified:

• unit tests for recovery after repeated errors and exit when shutdown happens mid-error-streak (failed on the old loop)
• live repro on Linux: forced EMFILE by capping the server's RLIMIT_NOFILE. On 0.9.1 the CLI stays dead after the limit is lifted. With this fix it recovers, and session stop still works
• just check

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: 3a5d53d3-49e4-4a2e-a97d-80799f3a78bd

📥 Commits

Reviewing files that changed from the base of the PR and between a3b5fa7 and 3c59674.

📒 Files selected for processing (1)

• src/api/server.rs

💤 Files with no reviewable changes (1)

• src/api/server.rs

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

---

📝 Walkthrough

Walkthrough

The API listener now retries accept errors after a 50 ms backoff while the server is running. It logs the first consecutive error. A successful accept resets the error count, and the accepted stream is handled on a separate thread. The loop checks server state after the backoff and exits when the server stops. Tests cover repeated accept errors and shutdown during continuing errors.

Priority: ⬇️ Low

Merge Risk: ⚪ Minimal · up to 3c596

The listener can retry transient accept errors without the identified shutdown-blocking risk. No issue requiring a pre-merge fix was established.

Security Architecture Review

Security architecture risk: 🔵 Low · up to a3b5f

The listener can recover from accept errors without changing who can connect or how requests are handled. No material security regression was established, though shutdown behavior under every runtime condition remains unverified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The recovery path restores availability of the same permission-restricted local socket. Evidence does not show a newly reachable transport, tenant, or privileged downstream service.

Trust Boundaries and Controls

• observed — Accept retries do not replace the local-socket permission restriction or the existing typed request parser and shutdown-response checks.

Resilience and Maintainability Implications

• inferred — A successful accept can race with shutdown because the loop checks its running flag only on errors. The base loop also dispatched successful accepts without that check, so this is not established as a PR-introduced control regression. Whether handle destruction unblocks a waiting accept remains unverified.

Hardening Proposals

• proposed — Consider explicitly coordinating listener termination with handle destruction and checking shutdown before dispatching a successful accept. This would strengthen an existing lifecycle boundary, not address an established regression from this PR.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 6 functions across 1 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: keeping the API listener alive after transient accept errors.
Description check	✅ Passed	The description directly explains the transient accept error problem, retry behavior, logging, testing, and recovery validation.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

---

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.}

[kangal-bot]

@coderabbitai review
@greptileai

[coderabbitai]

✅ Action performed

Review finished.

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.

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Changes how the API server handles connection accept errors.

The PR appears safe to merge.

Summary

The PR keeps the API listener accepting after transient errors, with a short backoff and tests for recovery and shutdown. The latest change removes per-retry debug logging so a sustained failure does not repeatedly fill the log.

_{Reviews (2) · Last reviewed commit: "fix: drop repeated api accept failure lo..."}

[ogulcancelik]

@coderabbitai review
@greptileai

[coderabbitai]

✅ Action performed

Review finished.

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.