Improve idle timer and connection log messages

[mattheworiordan]

Summary

When running Ably in a server-side environment (e.g. Temporal durable execution where connections are long-lived and transported), I started seeing repeated idle timer error log messages like:

19:53:09.769 Ably: Transport.onIdleTimerExpire(): No activity seen from realtime in 158448ms; assuming connection has dropped
20:08:14.963 Ably: Transport.onIdleTimerExpire(): No activity seen from realtime in 904542ms; assuming connection has dropped
20:15:46.999 Ably: Transport.onIdleTimerExpire(): No activity seen from realtime in 436798ms; assuming connection has dropped
21:17:06.799 Ably: Transport.onIdleTimerExpire(): No activity seen from realtime in 379413ms; assuming connection has dropped

These are confusing for developers because:

• They don't explain what the SDK will do next (is it disconnecting? reconnecting? is this fatal?)
• They don't include a connection ID, so with multiple connections you can't tell which one is affected
• There's no corresponding log when the connection recovers, so you see alarming messages with no resolution
• The error code (80003) is created internally but never shown in the log
• They refer to "realtime" instead of "Ably"

Note: I believe these disconnects are expected, they are probably triggered by me opening & closing my laptop

As we think about how Ably is increasingly used server-side, these messages need to be more useful. This is a quick win to make the logs actionable.

Changes

• Idle timer expiry: now includes connection ID, error code 80003/408, and states the SDK will disconnect and reconnect automatically
• Reconnection log: new LOG_MINOR message when connection is resumed or reestablished after disconnection — a bookend so you can see the resolution
• Connection state freshness: now explains that the connection state TTL was exceeded and a new connection will be established with channels reattaching; includes connection ID
• Naming: replace "realtime" with "Ably" in user-facing log messages

Test plan

• Existing idle_transport_timeout test passes
• Linter clean
• Review log output in a real server-side environment

🤖 Generated with Claude Code

Summary by CodeRabbit

• Chores
  • Improved logging clarity for connection transitions by indicating whether a connection was resumed or reestablished, and including the prior connection identifier when different.
  • Made idle-timeout disconnect messages more informative and Ably-specific, reporting freshness thresholds and (when available) the connection identifier; the message now includes the fixed error code 80003 and status 408.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f308d024-8c53-4b0c-a596-eabbf5b69b6e

📥 Commits

Reviewing files that changed from the base of the PR and between a134e70 and 90bc0ad.

📒 Files selected for processing (2)

• src/common/lib/transport/connectionmanager.ts
• src/common/lib/transport/transport.ts

✅ Files skipped from review due to trivial changes (2)

• src/common/lib/transport/transport.ts
• src/common/lib/transport/connectionmanager.ts

---

Walkthrough

Connection logging and idle-timeout error messages updated: ConnectionManager now logs resumed vs reestablished connections and adds Ably-specific diagnostics for freshness checks; Transport produces an Ably-formatted idle-timeout disconnect ErrorInfo (code 80003, status 408) that can include the connectionId.

Changes

Cohort / File(s)

Summary

Transport & ConnectionManager src/common/lib/transport/connectionmanager.ts, src/common/lib/transport/transport.ts

In activateTransport(), log whether a newly activated transport resumed (same connectionId) or reestablished (different connectionId), including the prior connectionId only when different. In checkConnectionStateFreshness(), update discard log to reference “Ably”, report sinceLast, the freshness threshold (this.connectionStateTtl + this.maxIdleInterval), threshold-exceeded status, and current connectionId when available. In Transport.onIdleTimerExpire(), construct and log an Ably-specific disconnect message (includes connectionId if present) and pass an ErrorInfo with code 80003 and status 408 to disconnect().

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 I hopped through logs with a curious grin,

IDs now sparkle where traces had been.
“Resumed” or “reestablished” — the tale's in the line,
Ably's whispers recorded, all tidy and fine. 🥕✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Improve idle timer and connection log messages' clearly and accurately summarizes the main changes in the pull request.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch improve-idle-timer-log-messages

---

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 and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/common/lib/transport/connectionmanager.ts`:
- Around line 893-899: The freshness log message incorrectly states that the TTL
(connectionStateTtl) was exceeded while the actual check compares sinceLast
against connectionStateTtl + maxIdleInterval; update the log to reflect the true
threshold by including both connectionStateTtl and maxIdleInterval (or the
summed threshold) in the message where sinceLast, connectionStateTtl,
maxIdleInterval and connectionId are referenced so the log accurately reports
the expiry condition that triggered discarding the connection state.
- Around line 676-689: The log computes whether the connection "resumed" by
comparing prevConnId to connectionId, but prevConnId is read after a possible
setConnection(...) mutation in ConnectionManager.activateTransport(), causing
reestablish events to be mislabeled as resumed; fix by capturing the existing
connectionId into a local variable (e.g., prevConnId) before any call that may
update the manager state (before setConnection/updateConnectionId), then compute
resumed = prevConnId === connectionId and use that stored prevConnId in the
Logger.logAction call so the log reflects the pre-update connection id.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 7a727441-bd8e-427f-9470-3b7777ff6243

📥 Commits

Reviewing files that changed from the base of the PR and between c90f1c3 and a134e70.

📒 Files selected for processing (2)

• src/common/lib/transport/connectionmanager.ts
• src/common/lib/transport/transport.ts