[FIXED] Combined stream scale up/down and subjects/sources update

[MauriceVanVeen]

A stream that was scaled up from R1 along with its subjects being updated would not subscribe to the new subjects. This PR fixes that by just subscribing to the new subjects when we were already actively subscribed to the others.

There was a similar issue where if a stream got scaled down to R1 but it wasn't the previous stream leader, the new server would not subscribe to any subjects or remove previous sources and require a restart.

Resolves #7996

Signed-off-by: Maurice van Veen github@mauricevanveen.com

[synadia-claude-reviewer]

Claude finished @MauriceVanVeen's task in 1m 55s —— View job

---

PR Review

• Gather context
• Read PR diff and changed files
• Analyze correctness and concurrency safety
• Post review findings

---

The fix is correct and minimal. Here's the analysis:

Root cause: When scaling R1→R3 and updating subjects simultaneously, updateWithAdvisory is called while the stream is transitioning from non-clustered to clustered. At that moment isClustered() becomes true, so isLeader() delegates to mset.node.Leader() — but the Raft node may not yet be elected, returning false. Meanwhile, mset.active is still true from the R1 phase (subscriptions are live). The old guard if mset.isLeader() skipped the subscription update, leaving "b" unsubscribed.

Why mset.active is the right guard:

• active is set to true only by subscribeToStream(), which is called exclusively from setLeader(true) — meaning it accurately tracks whether subscriptions are live and need updating.
• For steady-state followers, setLeader(false) calls unsubscribeToStream() → active = false, so the behavior for normal followers is unchanged.
• The only case where active == true and isLeader() == false is this exact transitional window — precisely where the fix is needed.

Concurrency: The check is under mset.mu.Lock(), and the subsequent subscribe/unsubscribe calls are correct. No races introduced.

Test: TestJetStreamClusterStreamUpdateCombinedScaleUpWithSubjectsChange directly exercises the failing scenario. Using checkFor with a 2s window accommodates leader election time. The AckWait(200ms) inside the retry loop is fine.

No issues found. LGTM.

[MauriceVanVeen]

@claude, brief re-review please, but also take the scale down issue into account.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5f818f3a17

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e916c63538

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e24271a6fc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[MauriceVanVeen]

@claude, brief re-review please.