fix: pin Netty to the gRPC-supported version in Spring modules

[javier-aliaga]

Description

The Spring Boot 4 migration (#1772) has the Dapr Spring modules import the Spring Boot 4 BOM, which manages Netty 4.2.x. The SDK uses the non-shaded grpc-netty (1.79.0), and per gRPC's compatibility matrix gRPC 1.79 targets Netty 4.1.x — no gRPC release supports Netty 4.2.x. Inside these modules grpc-netty is a compile-scope transitive (via dapr-sdk), so it was resolving onto an unsupported Netty line.

The concrete impact is on the SDK's own reactor: it was building and — more importantly — running its Spring integration tests and examples against a Netty version gRPC does not support (sdk-tests / spring-boot-sdk-tests exercise real gRPC over a Testcontainers daprd). In other words, "CI green" was validating gRPC on Netty 4.2.x, an untested combination that can fail with NoSuchMethodError / NoClassDefFoundError.

Scope note: downstream apps that import dapr-spring-bom are already protected — it pins Netty 4.1.132 transitively via dapr-sdk-bom. This change does not alter that; it aligns the SDK's own builds, tests, and examples with the same supported Netty version the core modules already use. The root pom.xml pins netty-bom 4.1.132, but the Spring modules override it by importing the Spring Boot BOM in their own dependencyManagement, so the pin never reached them.

Switching to grpc-netty-shaded is not an option — it was deliberately removed in #1543 because shaded Netty breaks native compilation (Quarkus / Spring Native), prevents patching Netty CVEs, and increases memory usage.

Fix

Import netty-bom (${netty.version} = 4.1.132) before spring-boot-dependencies in the gRPC-reachable Spring modules, so Maven's first-declared-wins rule keeps Netty on the gRPC-supported 4.1.x line:

• dapr-spring-boot-autoconfigure
• dapr-spring-data
• dapr-spring-boot-starter
• sdk-tests
• spring-boot-examples
• spring-boot-sdk-tests

dapr-spring-boot-starter-test pulls no Netty transitively, so it is intentionally left unpinned.

Verification

Resolved io.netty:netty-common via dependency:tree in each affected module — all now resolve 4.1.132.Final (previously 4.2.12.Final), matching the version already used by the core SDK.

Checklist

• Code compiles correctly
• Created/updated tests
• Extended the documentation (inline comment explaining the pin)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.85%. Comparing base (cc1c1a0) to head (a5134f1).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master    #1793   +/-   ##
=========================================
  Coverage     76.85%   76.85%           
  Complexity     2300     2300           
=========================================
  Files           244      244           
  Lines          7145     7145           
  Branches        748      748           
=========================================
  Hits           5491     5491           
  Misses         1288     1288           
  Partials        366      366           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[siri-varma]

@javier-aliaga I think we should do this in the parent pom. And just import it here. That way all the versions are in one single place.

Applies to changes in all other poms as well

[javier-aliaga]

I tried moving it to parent but then it resolves to 4.2.x instead of 4.1.x, I did a research and it seems as we import the spring-boot-dependencies it wins over the parent import, that is why we need it in every pom. To make it to the parent it would require a bigger refactor...