fix: persist preferred host updates correctly in HttpScheduler retry logic

[ttypic]

Resolves #1205

• Prevent successful response from re-establish fallback host as the preference after fallback timeout
• Ensured the preferred host is only updated when necessary during retry attempts

Summary by CodeRabbit

• Bug Fixes

  • Improved host fallback logic to prevent unnecessary switching of preferred hosts after successful fallback connections. The client now only updates the preferred host if the successful connection differs from the original, providing more stable connection behavior in scenarios with multiple hosts and timeout handling.

• Tests

  • Added comprehensive test coverage for fallback host behavior and timeout scenarios.

[coderabbitai]

Warning

Rate limit exceeded

@ttypic has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 22 minutes and 24 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 7127b9f1-5949-47b9-a0ee-e0b56bcfd88e

📥 Commits

Reviewing files that changed from the base of the PR and between c1dcc7b and d5ce2a7.

📒 Files selected for processing (1)

• lib/src/test/java/io/ably/lib/test/rest/HttpTest.java

Walkthrough

This change modifies host fallback pinning logic in the HTTP scheduler to only persist a successful fallback host when it differs from the original preferred host, and adds a test verifying that late-arriving responses don't trigger unwanted re-pinning after the fallback retry timeout expires.

Changes

Cohort / File(s)	Summary
Core Fallback Pinning Logic lib/src/main/java/io/ably/lib/http/HttpScheduler.java	Captures preferred host snapshot at request start and only sets a new preferred host on success if the successful candidate host differs from the original snapshot, preventing unnecessary re-pinning.
Fallback Timeout Behavior Test lib/src/test/java/io/ably/lib/test/rest/HttpTest.java	Adds integration test verifying that a delayed fallback response arriving after the retry timeout expires does not cause the client to re-pin the fallback host, ensuring correct timeout semantics.

Estimated Code Review Effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 A host snaps its picture, so wise and so keen,
With snapshots and comparisons, the best we have seen,
No re-pinning late guests after timeouts expire,
Fallback behavior perfected—the code we admire! 📌✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%.	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 accurately describes the main change: fixing how the preferred host is persisted in HttpScheduler retry logic, which aligns with the changeset that prevents re-pinning fallback hosts after timeout.
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.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ECO-5705/fix-host-repin

---

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

_{Review rate limit: 0/1 reviews remaining, refill in 22 minutes and 24 seconds.}

_{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 `@lib/src/main/java/io/ably/lib/http/HttpScheduler.java`:
- Around line 199-210: The current repinning logic compares candidateHost to the
preferredHost captured at request start (preferredHost / candidateHost) which
can incorrectly repin if the original pin expired during the request; change the
check before calling httpCore.hosts.setPreferredHost(candidateHost, true) to
verify the current preferred host and pin age/validity instead of the
start-of-request string — fetch the live preferred host and its pin expiry/age
from httpCore.hosts (or add an accessor like
getPreferredHostExpiry/isPreferredHostPinned) after httpExecuteWithRetry
returns, and only call httpCore.hosts.setPreferredHost(candidateHost, true) if
candidateHost differs from the current live preferred host and the existing pin
is expired/older than fallbackRetryTimeout (or otherwise invalid). Ensure the
change touches the block that calls httpExecuteWithRetry(...) and the subsequent
setPreferredHost(...) call so persistence is gated on current pin validity
rather than the initial preferredHost snapshot.

In `@lib/src/test/java/io/ably/lib/test/rest/HttpTest.java`:
- Around line 1479-1500: The test creates an ExecutorService named executor for
requestFuture but never guarantees shutdown on failures; wrap the code that uses
executor/ requestFuture/ delayedRequestStarted in a try { ... } finally { ... }
block and call executor.shutdownNow() (or shutdown() then awaitTermination) in
the finally to ensure the single-thread executor is always cleaned up; keep
existing assertions and requestFuture.get() inside the try and perform executor
shutdown/termination in the finally to avoid stray test threads.

🪄 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: 086a75d9-c331-4a12-974e-92f411409ff8

📥 Commits

Reviewing files that changed from the base of the PR and between 5c75ea3 and c1dcc7b.

📒 Files selected for processing (2)

• lib/src/main/java/io/ably/lib/http/HttpScheduler.java
• lib/src/test/java/io/ably/lib/test/rest/HttpTest.java

[Copilot]

Pull request overview

Fixes a race in REST HTTP fallback handling where a late-arriving success from a previously-preferred fallback host could re-pin that fallback after its fallbackRetryTimeout had already expired (RSC15f / issue #1205).

Changes:

• Update HttpScheduler fallback retry loop to only persist a preferred host when the successful host differs from the originally-selected preferred host for that request.
• Add a regression test that simulates an in-flight fallback request completing after the fallback preference has expired and been cleared by a concurrent request.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
lib/src/main/java/io/ably/lib/http/HttpScheduler.java	Prevents late successes from re-persisting an originally-preferred host by persisting only when the successful host differs from the request’s initial preferred host.
lib/src/test/java/io/ably/lib/test/rest/HttpTest.java	Adds a concurrency/timing regression test covering the late-success-after-expiry scenario.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.