Bulk dependency update

[BrainHorse]

Updated:

• org.typelevel:cats-effect: 3.6.3 -> 3.7.1
• berlin.yuna:nats-server: 2.12.1 -> 2.15.0
• org.typelevel:weaver-cats: 0.10.1 -> 0.13.0
• com.evolutiongaming:cats-helper-logback: 3.12.2 -> 3.13.1
• com.evolutiongaming:smetrics: 2.3.4 -> 3.0.0 (major version bump)
• sbt: 2.0.4 -> 2.0.9

Skipped:

• com.olegpy:better-monadic-for and all sbt plugins (sbt-bloop, sbt-version-policy, sbt-artifactory-plugin, sbt-dynver, sbt-ide-settings, sbt-scalafmt, sbt-scoverage) are already at their latest versions.

Notable changes:

• com.evolutiongaming:smetrics 2.3.4 -> 3.0.0: applied the major bump directly. The release notes document no breaking API changes.
• org.typelevel:weaver-cats 0.10.1 -> 0.13.0: upstream renamed several APIs across this range (MutableIOSuite to IOSuite, ExpectationFailed to ExpectationsFailed, Suite[F] to EffectSuite[F]; see the release notes). This project doesn't reference any of the renamed symbols, so it compiled without changes.
• io.nats:jnats 2.25.1 -> 2.26.3: Options.Builder#enableFastFallback is now deprecated. Migrated to hostnameResolveMode(HostnameResolveMode.HappyEyeballs) in core/.../impl/package.scala.
• org.typelevel:cats-effect 3.6.3 -> 3.7.1: cats.effect.std.Hotswap is now deprecated in favor of NonEmptyHotswap. Migrated DynamicKeyValueReader to the new API, which also drops the Option handling since NonEmptyHotswap always holds a value.

Changelogs

• org.typelevel:cats-effect 3.6.3 -> 3.7.1
• berlin.yuna:nats-server 2.12.1 -> 2.15.0
• org.typelevel:weaver-cats 0.10.1 -> 0.13.0
• com.evolutiongaming:cats-helper-logback 3.12.2 -> 3.13.1
• com.evolutiongaming:smetrics 2.3.4 -> 3.0.0
• org.scala-sbt:sbt 2.0.4 -> 2.0.9

Summary by CodeRabbit

• Maintenance
  • Updated the underlying platform components and supporting tooling.
• Reliability
  • Dynamic key-value readers now consistently use an available reader when retrieving values, listing keys, and updating filters.

[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: evolution-gaming/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: f85e8b47-1b7c-4647-b0c1-6297a19b7692

📥 Commits

Reviewing files that changed from the base of the PR and between e077266 and a27701b.

📒 Files selected for processing (1)

• core/build.sbt

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

---

📝 Walkthrough

Walkthrough

The dynamic key-value reader now uses NonEmptyHotswap to hold its reader. The project also updates dependency versions and the SBT version. The jnats version remains unchanged.

Changes

Dynamic key-value reader

Layer / File(s)	Summary
Use a non-empty reader hot swap jetstream/src/main/scala/com/evolution/natseffect/jetstream/DynamicKeyValueReader.scala	Impl and its constructor use NonEmptyHotswap. get, keys, and updateFilters access the current reader directly.

Build and dependency updates

Layer / File(s)	Summary
Update build versions core/build.sbt, loadtest/build.sbt, logback/build.sbt, metrics/build.sbt, project/build.properties	The build updates cats-effect, test nats-server, weaver-cats, cats-helper-logback, smetrics, and SBT. A comment cautions against upgrading jnats without syncing with its Java API; the jnats version remains unchanged.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Other

Merge Risk: ⚪ Minimal · up to a2770

The dynamic reader is initialized before use, and the dependency changes show no concrete compatibility failure in the inspected APIs. No user-facing regression is established; normal build and CI checks should still confirm readiness.

Architecture Summary

Architecture risk: 🔵 Low · up to a2770

The change affects 6 systems.

Changed systems: core, jetstream, loadtest, logback, metrics, project

Architecture concerns
No architecture-level concerns identified.

Review details

Systems and components

• observed — core (service) was modified; 1 changed file maps to changed impact.
• observed — jetstream (service) was modified; 1 changed file maps to changed impact.
• observed — loadtest (service) was modified; 1 changed file maps to changed impact.
• observed — logback (service) was modified; 1 changed file maps to changed impact.

Before / after behavior

• observed — Modified behavior in jetstream/src/main/scala/com/evolution/natseffect/jetstream/DynamicKeyValueReader.scala: The imports replace Hotswap with NonEmptyHotswap.
• observed — Modified behavior in jetstream/src/main/scala/com/evolution/natseffect/jetstream/DynamicKeyValueReader.scala: Impl now holds a NonEmptyHotswap. get and keys use the reader directly rather than flattening optional results or returning an empty set when no reader is present; updateFilters reads the current reader’s filters directly rather than defaulting to an empty set.
• observed — Modified behavior in jetstream/src/main/scala/com/evolution/natseffect/jetstream/DynamicKeyValueReader.scala: make creates a NonEmptyHotswap for the initial reader instead of a Hotswap.
• observed — Modified behavior in loadtest/build.sbt: The nats-server dependency version changed from 2.12.1 to 2.15.0.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
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.
Title check	✅ Passed	The title accurately identifies the primary change: multiple dependencies and build tools were updated. It is concise and clear, although it does not mention the smaller DynamicKeyValueReader change.

✨ Finishing Touches 💡 1

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

🛠️ Fix failing CI checks 💡

• Commit to this branch
• Create a new PR

---

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

[DeviLab]

There are some changes in JNATS public API which should be added to our Options:
https://github.com/nats-io/nats.java/pull/1536/changes - hostnameResolveMode
https://github.com/nats-io/nats.java/pull/1578/changes - reconnectDelayBehavior
https://github.com/nats-io/nats.java/pull/1582/changes - advancedRequestBehavior
https://github.com/nats-io/nats.java/pull/1583/changes - configurable reader/writer executor

[BrainHorse]

@DeviLab I assume this can be done in a separate pull request. This change is about updating the dependencies rather than keeping the Options class in sync with the Java implementation. There are no guidelines in the project for doing such a thing.

[kromanovs]

Looks logical to either

• separate that Options change from current libs update or
• exclude jnats update from this MR and then do another one with jnats+Options at the same time.

[DeviLab]

Bumping JNATS without updating API for new features has very little sense and increases a technical debt. The simplest way to update API is exactly during dependencies updates because the changelog is reviewed anyway. I don't mind if JNATS version will be bumped later, but I'm not okay that the API in master is not synchronized with JNATS and there is no clear plan/intention to fix it.

[BrainHorse]

Bumping JNATS without updating API for new features has very little sense and increases a technical debt.

You can't control whether jnants will be updated in consumer projects. If it is updated by a consumer, the features you want to keep in sync won't be received, hence your statement "has very little sense"

I don't mind if JNATS version will be bumped later

I reverted the update and added a comment so you can do a bump later

[kromanovs]

Looks good to me now without the jnats bump

[DeviLab]

I can't control whether JNATS will be updated, but it's clearly mentioned in README.MD that backward compatibility is not guaranteed if the version is changed manually:

You can try to override the Java NATS client version, but compatibility is not guaranteed.