dependabot[bot] opened a new pull request, #792:
URL: https://github.com/apache/mina-sshd/pull/792

   Bumps `grpc.version` from 1.73.0 to 1.74.0.
   Updates `io.grpc:grpc-netty-shaded` from 1.73.0 to 1.74.0
   <details>
   <summary>Release notes</summary>
   <p><em>Sourced from <a 
href="https://github.com/grpc/grpc-java/releases";>io.grpc:grpc-netty-shaded's 
releases</a>.</em></p>
   <blockquote>
   <h2>v1.74.0</h2>
   <h3>Behavior Changes</h3>
   <ul>
   <li>compiler: Default to <code>@generated=omit</code> (f8700a13a). This 
omits <code>javax.annotation.Generated</code> from the generated code and makes 
the <code>org.apache.tomcat:annotations-api</code> compile-only dependency 
unnecessary (README and examples changes forthcoming; we delayed those changes 
until the release landed). You can use the option <code>@generated=javax</code> 
for the previous behavior, but please also file an issue so we can develop 
alternatives</li>
   <li>compiler: generate blocking v2 unary calls that throw StatusException 
(<a href="https://redirect.github.com/grpc/grpc-java/issues/12126";>#12126</a>) 
(a16d65591). Previously, the new blocking stub API was identical to the older 
blocking stub for unary RPCs and used the unchecked 
<code>StatusRuntimeException</code>. However, feedback demonstrated it was 
confusing to mix that with the checked <code>StatusException</code> in 
<code>BlockingClientCall</code>. Now the new blocking stub uses StatusException 
throughout. grpc-java continues to support the old generated code, but the 
version of protoc-gen-grpc-java will dictate which API you see. If you support 
multiple generated code versions, you can use the older blocking v1 stub for 
unary RPCs</li>
   </ul>
   <h3>Bug Fixes</h3>
   <ul>
   <li>netty: Fix a race that caused RPCs to hang on start when a GOAWAY was 
received while the RPCs’ headers were being written to the OS (b04c673fd, 
15c757398). This was a very old race, not a recent regression. All streams 
should now properly fail instead of hanging, although in some cases they may be 
transparently retried</li>
   <li>util: OutlierDetection should use nanoTime, not currentTimeMillis (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12110";>#12110</a>) 
(1c4309899). Previously, changes in the wall time would impact its 
accounting</li>
   <li>xds: Don't allow hostnames in address field in EDS (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12123";>#12123</a>) 
(482dc5c1c). Only IP addresses were handled properly, and only IP addresses 
should be handled per gRFC A27</li>
   <li>xds: In resource handling, call onError() for RDS and EDS NACKs (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12122";>#12122</a>) 
(efe9ccc22). Previously the resource was NACKed, but gRPC would continue 
waiting for the resource until a timeout was reached and claim the control 
plane didn’t send the resource. Now it will fail quickly with an informative 
error</li>
   <li>xds: Implement equals in RingHashConfig (a5eaa66cc). Previously all 
configuration refreshes were considered a new config, which had the potential 
for causing unexpected inefficiency problems. This was noticed by new code for 
gRFC A74 xDS Config Tears that is not yet enabled, so there are no known 
problems that this caused</li>
   <li>LBs should avoid calling LBs after lb.shutdown() (1df2a3305). This fixed 
pick_first and ring_hash behavior that could cause rare and “random” races in 
parent load balancers like a <code>NullPointerException</code> in 
<code>ClusterImplLoadBalancer.createSubchannel()</code>, which had a ring_hash 
child. This is most likely to help xDS, as it heavily uses hierarchical LB 
policies</li>
   </ul>
   <h3>Improvements</h3>
   <ul>
   <li>util: Deliver addresses in a random order to shuffle connection creation 
ordering (f07eb47ca). Previously, connections were created in-order (but 
non-blocking), so in a fast network the first address could be more likely to 
connect first given a &quot;microsecond&quot; headstart. That first connection 
then receives all the buffered RPCs, which could cause temporary, but repeated, 
load imbalances of the same backend when all clients receive the same list of 
addresses in the same order. This has been seen in practice, but it is unclear 
how often it happens. Shuffling has the potential to improve load distribution 
of new clients when using round_robin, weighted_round_robin, and least_request, 
which connect simultaneously to multiple addresses</li>
   <li>core: Use lazy message formatting in checkState (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12144";>#12144</a>) 
(26bd0eee4). This avoids the potential of unnecessarily formatting an exception 
as a string when a subchannel fails to connect</li>
   <li>bazel: Migrate java_grpc_library to use DefaultInfo (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12148";>#12148</a>) 
(6f69363d9). This adds compatibility for 
<code>--incompatible_disable_target_default_provider_fields</code></li>
   <li>binder: Rationalize <a 
href="https://github.com/ThreadSafe-ty";><code>@​ThreadSafe-ty</code></a> inside 
BinderTransport (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12130";>#12130</a>) 
(c20642874)</li>
   <li>binder: Cancel checkAuthorization() request if still pending upon 
termination (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12167";>#12167</a>) 
(30d40a617)</li>
   </ul>
   <h3>Dependencies</h3>
   <ul>
   <li>compiler: Upgrade Protobuf C++ to 22.5 (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/11961";>#11961</a>) 
(46485c8b6). This is used by the pre-built protoc-gen-grpc-java plugin on Maven 
Central. This should have no visible benefit, but gets us closer to upgrading 
to Protobuf 27 which added edition 2023 support</li>
   <li>release: Migrate artifacts publishing changed from legacy OSSRH to 
Central Portal (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12156";>#12156</a>) 
(f99b2aaef). We aren’t aware of any visible changes to the results on Maven 
Central</li>
   </ul>
   </blockquote>
   </details>
   <details>
   <summary>Commits</summary>
   <ul>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/9d2c895c29ad505ea564ccf9369678e5478152e5";><code>9d2c895</code></a>
 Bump version to 1.74.0</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/b58900e759483272f6aa12bb8038cf178e62d803";><code>b58900e</code></a>
 Update README etc to reference 1.74.0</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/15c7573988fab5c9893c1d86f0d23f1cd4b683f8";><code>15c7573</code></a>
 netty: Associate netty stream eagerly to avoid client hang</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/b04c673fdfec6191afdca06fa254b9e4da0150f6";><code>b04c673</code></a>
 Guarantee missing stream promise delivery</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/1df2a330568b2131fd2fda77cf85c948dba19ae0";><code>1df2a33</code></a>
 LBs should avoid calling LBs after lb.shutdown()</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/a5eaa66ccc2add0c9b78096ca3196ec1c7904c1f";><code>a5eaa66</code></a>
 xds: Implement equals in RingHashConfig</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/393f02b117a2c2e204029274a9266b5c64124062";><code>393f02b</code></a>
 Revert &quot;xds: Convert CdsLb to XdsDepManager&quot;</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/69b8cf5f2611c580fa1e5ee3a4ad9e42919e49c6";><code>69b8cf5</code></a>
 Revert &quot;xds: Support tracking non-xds resources in 
XdsDepManager&quot;</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/98e4252e3408e804162a86e38466a90c5d10a817";><code>98e4252</code></a>
 Revert &quot;xds: XdsNR should be subscribing to clusters with 
XdsDepManager&quot;</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/3b63af411d32bb274a69bb14b1e5aac8ffca2f45";><code>3b63af4</code></a>
 Revert &quot;xds: Add logical dns cluster support to XdsDepManager&quot;</li>
   <li>Additional commits viewable in <a 
href="https://github.com/grpc/grpc-java/compare/v1.73.0...v1.74.0";>compare 
view</a></li>
   </ul>
   </details>
   <br />
   
   Updates `io.grpc:grpc-protobuf` from 1.73.0 to 1.74.0
   <details>
   <summary>Release notes</summary>
   <p><em>Sourced from <a 
href="https://github.com/grpc/grpc-java/releases";>io.grpc:grpc-protobuf's 
releases</a>.</em></p>
   <blockquote>
   <h2>v1.74.0</h2>
   <h3>Behavior Changes</h3>
   <ul>
   <li>compiler: Default to <code>@generated=omit</code> (f8700a13a). This 
omits <code>javax.annotation.Generated</code> from the generated code and makes 
the <code>org.apache.tomcat:annotations-api</code> compile-only dependency 
unnecessary (README and examples changes forthcoming; we delayed those changes 
until the release landed). You can use the option <code>@generated=javax</code> 
for the previous behavior, but please also file an issue so we can develop 
alternatives</li>
   <li>compiler: generate blocking v2 unary calls that throw StatusException 
(<a href="https://redirect.github.com/grpc/grpc-java/issues/12126";>#12126</a>) 
(a16d65591). Previously, the new blocking stub API was identical to the older 
blocking stub for unary RPCs and used the unchecked 
<code>StatusRuntimeException</code>. However, feedback demonstrated it was 
confusing to mix that with the checked <code>StatusException</code> in 
<code>BlockingClientCall</code>. Now the new blocking stub uses StatusException 
throughout. grpc-java continues to support the old generated code, but the 
version of protoc-gen-grpc-java will dictate which API you see. If you support 
multiple generated code versions, you can use the older blocking v1 stub for 
unary RPCs</li>
   </ul>
   <h3>Bug Fixes</h3>
   <ul>
   <li>netty: Fix a race that caused RPCs to hang on start when a GOAWAY was 
received while the RPCs’ headers were being written to the OS (b04c673fd, 
15c757398). This was a very old race, not a recent regression. All streams 
should now properly fail instead of hanging, although in some cases they may be 
transparently retried</li>
   <li>util: OutlierDetection should use nanoTime, not currentTimeMillis (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12110";>#12110</a>) 
(1c4309899). Previously, changes in the wall time would impact its 
accounting</li>
   <li>xds: Don't allow hostnames in address field in EDS (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12123";>#12123</a>) 
(482dc5c1c). Only IP addresses were handled properly, and only IP addresses 
should be handled per gRFC A27</li>
   <li>xds: In resource handling, call onError() for RDS and EDS NACKs (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12122";>#12122</a>) 
(efe9ccc22). Previously the resource was NACKed, but gRPC would continue 
waiting for the resource until a timeout was reached and claim the control 
plane didn’t send the resource. Now it will fail quickly with an informative 
error</li>
   <li>xds: Implement equals in RingHashConfig (a5eaa66cc). Previously all 
configuration refreshes were considered a new config, which had the potential 
for causing unexpected inefficiency problems. This was noticed by new code for 
gRFC A74 xDS Config Tears that is not yet enabled, so there are no known 
problems that this caused</li>
   <li>LBs should avoid calling LBs after lb.shutdown() (1df2a3305). This fixed 
pick_first and ring_hash behavior that could cause rare and “random” races in 
parent load balancers like a <code>NullPointerException</code> in 
<code>ClusterImplLoadBalancer.createSubchannel()</code>, which had a ring_hash 
child. This is most likely to help xDS, as it heavily uses hierarchical LB 
policies</li>
   </ul>
   <h3>Improvements</h3>
   <ul>
   <li>util: Deliver addresses in a random order to shuffle connection creation 
ordering (f07eb47ca). Previously, connections were created in-order (but 
non-blocking), so in a fast network the first address could be more likely to 
connect first given a &quot;microsecond&quot; headstart. That first connection 
then receives all the buffered RPCs, which could cause temporary, but repeated, 
load imbalances of the same backend when all clients receive the same list of 
addresses in the same order. This has been seen in practice, but it is unclear 
how often it happens. Shuffling has the potential to improve load distribution 
of new clients when using round_robin, weighted_round_robin, and least_request, 
which connect simultaneously to multiple addresses</li>
   <li>core: Use lazy message formatting in checkState (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12144";>#12144</a>) 
(26bd0eee4). This avoids the potential of unnecessarily formatting an exception 
as a string when a subchannel fails to connect</li>
   <li>bazel: Migrate java_grpc_library to use DefaultInfo (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12148";>#12148</a>) 
(6f69363d9). This adds compatibility for 
<code>--incompatible_disable_target_default_provider_fields</code></li>
   <li>binder: Rationalize <a 
href="https://github.com/ThreadSafe-ty";><code>@​ThreadSafe-ty</code></a> inside 
BinderTransport (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12130";>#12130</a>) 
(c20642874)</li>
   <li>binder: Cancel checkAuthorization() request if still pending upon 
termination (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12167";>#12167</a>) 
(30d40a617)</li>
   </ul>
   <h3>Dependencies</h3>
   <ul>
   <li>compiler: Upgrade Protobuf C++ to 22.5 (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/11961";>#11961</a>) 
(46485c8b6). This is used by the pre-built protoc-gen-grpc-java plugin on Maven 
Central. This should have no visible benefit, but gets us closer to upgrading 
to Protobuf 27 which added edition 2023 support</li>
   <li>release: Migrate artifacts publishing changed from legacy OSSRH to 
Central Portal (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12156";>#12156</a>) 
(f99b2aaef). We aren’t aware of any visible changes to the results on Maven 
Central</li>
   </ul>
   </blockquote>
   </details>
   <details>
   <summary>Commits</summary>
   <ul>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/9d2c895c29ad505ea564ccf9369678e5478152e5";><code>9d2c895</code></a>
 Bump version to 1.74.0</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/b58900e759483272f6aa12bb8038cf178e62d803";><code>b58900e</code></a>
 Update README etc to reference 1.74.0</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/15c7573988fab5c9893c1d86f0d23f1cd4b683f8";><code>15c7573</code></a>
 netty: Associate netty stream eagerly to avoid client hang</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/b04c673fdfec6191afdca06fa254b9e4da0150f6";><code>b04c673</code></a>
 Guarantee missing stream promise delivery</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/1df2a330568b2131fd2fda77cf85c948dba19ae0";><code>1df2a33</code></a>
 LBs should avoid calling LBs after lb.shutdown()</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/a5eaa66ccc2add0c9b78096ca3196ec1c7904c1f";><code>a5eaa66</code></a>
 xds: Implement equals in RingHashConfig</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/393f02b117a2c2e204029274a9266b5c64124062";><code>393f02b</code></a>
 Revert &quot;xds: Convert CdsLb to XdsDepManager&quot;</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/69b8cf5f2611c580fa1e5ee3a4ad9e42919e49c6";><code>69b8cf5</code></a>
 Revert &quot;xds: Support tracking non-xds resources in 
XdsDepManager&quot;</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/98e4252e3408e804162a86e38466a90c5d10a817";><code>98e4252</code></a>
 Revert &quot;xds: XdsNR should be subscribing to clusters with 
XdsDepManager&quot;</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/3b63af411d32bb274a69bb14b1e5aac8ffca2f45";><code>3b63af4</code></a>
 Revert &quot;xds: Add logical dns cluster support to XdsDepManager&quot;</li>
   <li>Additional commits viewable in <a 
href="https://github.com/grpc/grpc-java/compare/v1.73.0...v1.74.0";>compare 
view</a></li>
   </ul>
   </details>
   <br />
   
   Updates `io.grpc:grpc-stub` from 1.73.0 to 1.74.0
   <details>
   <summary>Release notes</summary>
   <p><em>Sourced from <a 
href="https://github.com/grpc/grpc-java/releases";>io.grpc:grpc-stub's 
releases</a>.</em></p>
   <blockquote>
   <h2>v1.74.0</h2>
   <h3>Behavior Changes</h3>
   <ul>
   <li>compiler: Default to <code>@generated=omit</code> (f8700a13a). This 
omits <code>javax.annotation.Generated</code> from the generated code and makes 
the <code>org.apache.tomcat:annotations-api</code> compile-only dependency 
unnecessary (README and examples changes forthcoming; we delayed those changes 
until the release landed). You can use the option <code>@generated=javax</code> 
for the previous behavior, but please also file an issue so we can develop 
alternatives</li>
   <li>compiler: generate blocking v2 unary calls that throw StatusException 
(<a href="https://redirect.github.com/grpc/grpc-java/issues/12126";>#12126</a>) 
(a16d65591). Previously, the new blocking stub API was identical to the older 
blocking stub for unary RPCs and used the unchecked 
<code>StatusRuntimeException</code>. However, feedback demonstrated it was 
confusing to mix that with the checked <code>StatusException</code> in 
<code>BlockingClientCall</code>. Now the new blocking stub uses StatusException 
throughout. grpc-java continues to support the old generated code, but the 
version of protoc-gen-grpc-java will dictate which API you see. If you support 
multiple generated code versions, you can use the older blocking v1 stub for 
unary RPCs</li>
   </ul>
   <h3>Bug Fixes</h3>
   <ul>
   <li>netty: Fix a race that caused RPCs to hang on start when a GOAWAY was 
received while the RPCs’ headers were being written to the OS (b04c673fd, 
15c757398). This was a very old race, not a recent regression. All streams 
should now properly fail instead of hanging, although in some cases they may be 
transparently retried</li>
   <li>util: OutlierDetection should use nanoTime, not currentTimeMillis (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12110";>#12110</a>) 
(1c4309899). Previously, changes in the wall time would impact its 
accounting</li>
   <li>xds: Don't allow hostnames in address field in EDS (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12123";>#12123</a>) 
(482dc5c1c). Only IP addresses were handled properly, and only IP addresses 
should be handled per gRFC A27</li>
   <li>xds: In resource handling, call onError() for RDS and EDS NACKs (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12122";>#12122</a>) 
(efe9ccc22). Previously the resource was NACKed, but gRPC would continue 
waiting for the resource until a timeout was reached and claim the control 
plane didn’t send the resource. Now it will fail quickly with an informative 
error</li>
   <li>xds: Implement equals in RingHashConfig (a5eaa66cc). Previously all 
configuration refreshes were considered a new config, which had the potential 
for causing unexpected inefficiency problems. This was noticed by new code for 
gRFC A74 xDS Config Tears that is not yet enabled, so there are no known 
problems that this caused</li>
   <li>LBs should avoid calling LBs after lb.shutdown() (1df2a3305). This fixed 
pick_first and ring_hash behavior that could cause rare and “random” races in 
parent load balancers like a <code>NullPointerException</code> in 
<code>ClusterImplLoadBalancer.createSubchannel()</code>, which had a ring_hash 
child. This is most likely to help xDS, as it heavily uses hierarchical LB 
policies</li>
   </ul>
   <h3>Improvements</h3>
   <ul>
   <li>util: Deliver addresses in a random order to shuffle connection creation 
ordering (f07eb47ca). Previously, connections were created in-order (but 
non-blocking), so in a fast network the first address could be more likely to 
connect first given a &quot;microsecond&quot; headstart. That first connection 
then receives all the buffered RPCs, which could cause temporary, but repeated, 
load imbalances of the same backend when all clients receive the same list of 
addresses in the same order. This has been seen in practice, but it is unclear 
how often it happens. Shuffling has the potential to improve load distribution 
of new clients when using round_robin, weighted_round_robin, and least_request, 
which connect simultaneously to multiple addresses</li>
   <li>core: Use lazy message formatting in checkState (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12144";>#12144</a>) 
(26bd0eee4). This avoids the potential of unnecessarily formatting an exception 
as a string when a subchannel fails to connect</li>
   <li>bazel: Migrate java_grpc_library to use DefaultInfo (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12148";>#12148</a>) 
(6f69363d9). This adds compatibility for 
<code>--incompatible_disable_target_default_provider_fields</code></li>
   <li>binder: Rationalize <a 
href="https://github.com/ThreadSafe-ty";><code>@​ThreadSafe-ty</code></a> inside 
BinderTransport (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12130";>#12130</a>) 
(c20642874)</li>
   <li>binder: Cancel checkAuthorization() request if still pending upon 
termination (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12167";>#12167</a>) 
(30d40a617)</li>
   </ul>
   <h3>Dependencies</h3>
   <ul>
   <li>compiler: Upgrade Protobuf C++ to 22.5 (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/11961";>#11961</a>) 
(46485c8b6). This is used by the pre-built protoc-gen-grpc-java plugin on Maven 
Central. This should have no visible benefit, but gets us closer to upgrading 
to Protobuf 27 which added edition 2023 support</li>
   <li>release: Migrate artifacts publishing changed from legacy OSSRH to 
Central Portal (<a 
href="https://redirect.github.com/grpc/grpc-java/issues/12156";>#12156</a>) 
(f99b2aaef). We aren’t aware of any visible changes to the results on Maven 
Central</li>
   </ul>
   </blockquote>
   </details>
   <details>
   <summary>Commits</summary>
   <ul>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/9d2c895c29ad505ea564ccf9369678e5478152e5";><code>9d2c895</code></a>
 Bump version to 1.74.0</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/b58900e759483272f6aa12bb8038cf178e62d803";><code>b58900e</code></a>
 Update README etc to reference 1.74.0</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/15c7573988fab5c9893c1d86f0d23f1cd4b683f8";><code>15c7573</code></a>
 netty: Associate netty stream eagerly to avoid client hang</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/b04c673fdfec6191afdca06fa254b9e4da0150f6";><code>b04c673</code></a>
 Guarantee missing stream promise delivery</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/1df2a330568b2131fd2fda77cf85c948dba19ae0";><code>1df2a33</code></a>
 LBs should avoid calling LBs after lb.shutdown()</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/a5eaa66ccc2add0c9b78096ca3196ec1c7904c1f";><code>a5eaa66</code></a>
 xds: Implement equals in RingHashConfig</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/393f02b117a2c2e204029274a9266b5c64124062";><code>393f02b</code></a>
 Revert &quot;xds: Convert CdsLb to XdsDepManager&quot;</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/69b8cf5f2611c580fa1e5ee3a4ad9e42919e49c6";><code>69b8cf5</code></a>
 Revert &quot;xds: Support tracking non-xds resources in 
XdsDepManager&quot;</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/98e4252e3408e804162a86e38466a90c5d10a817";><code>98e4252</code></a>
 Revert &quot;xds: XdsNR should be subscribing to clusters with 
XdsDepManager&quot;</li>
   <li><a 
href="https://github.com/grpc/grpc-java/commit/3b63af411d32bb274a69bb14b1e5aac8ffca2f45";><code>3b63af4</code></a>
 Revert &quot;xds: Add logical dns cluster support to XdsDepManager&quot;</li>
   <li>Additional commits viewable in <a 
href="https://github.com/grpc/grpc-java/compare/v1.73.0...v1.74.0";>compare 
view</a></li>
   </ul>
   </details>
   <br />
   
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   <details>
   <summary>Dependabot commands and options</summary>
   <br />
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot show <dependency name> ignore conditions` will show all of 
the ignore conditions of the specified dependency
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   </details>


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Reply via email to