Add tiered send/receive recovery to azure-core-amqp and azure-messaging-servicebus by EldertGrootenboer · Pull Request #48460 · Azure/azure-sdk-for-java

Eldert Grootenboer (EldertGrootenboer) · 2026-03-18T03:10:53Z

What this PR does

Adds tiered send/receive recovery to azure-core-amqp and azure-messaging-servicebus, matching the recovery pattern used by the Go, .NET, Python, and JS SDKs. When an AMQP operation fails, the error is classified into a recovery tier — NONE, LINK, CONNECTION, or FATAL — and the appropriate resources are closed before retrying.

This resolves a long-standing issue where a single stale AMQP connection or link could cause a Service Bus sender or receiver to become permanently stuck, requiring a JVM restart.

Changes

azure-core-amqp (shared — benefits Event Hubs too)

RecoveryKind (new): Error classification enum with classify(Throwable) that maps every AmqpErrorCondition to NONE/LINK/CONNECTION/FATAL. Also classifies IllegalStateException("Cannot publish ... disposed") as LINK so a stale ReactorSender is recovered instead of treated as fatal.
ReactorConnectionCache.invalidateConnection() (new): Marks the cached connection for force-invalidation via an AtomicReference<String> forceInvalidateConnectionId keyed on the connection's id. The next get() consumes the marker, closes the targeted connection, and supplies a fresh one. Targeting a specific connection-id prevents the AB-A race where a freshly created replacement connection could be evicted by a stale marker.
AmqpChannelProcessor.forceCloseChannel() (new): Same role for the v1 connection cache.
RetryUtil: No new public API. Recovery is composed at each call site using the existing withRetry(...) overloads with an onErrorResume(recoverBeforeRetry...) step that classifies the error, performs tier-appropriate cleanup (close link, invalidate connection), then re-emits the error so withRetry retries on the now-clean state.

azure-messaging-servicebus

Sender: All link-acquiring paths (createMessageBatch, scheduleMessageInternal, sendBatchInternal, sendFluxInternal) wrap link acquisition with RetryUtil.withRetry(...) + onErrorResume(recoverBeforeRetry). A new getSendLinkAndSizeWithRetry() helper wraps both getSendLink() and link.getLinkSize() inside the same retry boundary so a transient size-negotiation failure also triggers tiered recovery.
Receiver: Receive link creation uses the same retry + recovery composition with session removal on LINK errors and connectionCacheWrapper.invalidateConnection() on CONNECTION errors.
Session acquirer: Retry.from(...) includes a RecoveryKind.CONNECTION branch that calls connectionCacheWrapper.invalidateConnection() followed by Mono.delay(Duration.ZERO) so the session-acquisition retry continues on a fresh connection instead of falling through to terminal error handling.
Session manager: LINK and CONNECTION errors share a single retry branch returning Mono.delay(Duration.ZERO), with CONNECTION additionally calling invalidateConnection().
ConnectionCacheWrapper.invalidateConnection(): Delegates to v1 (AmqpChannelProcessor.forceCloseChannel()) or v2 (ReactorConnectionCache.invalidateConnection()) depending on which cache is active.

Tests

RecoveryKindTest (new, 215 lines): Covers all error condition classifications including the LINK reclassifications for OPERATION_CANCELLED, the NONE reclassification for RESOURCE_LIMIT_EXCEEDED, and the narrowed IllegalStateException("Cannot publish ... disposed") LINK match (with negative cases for unrelated disposal messages).
ReactorConnectionCacheTest (3 new tests): invalidateConnection() causes the next get() to close the cached connection and supply a new one; AB-A safety (stale marker does not invalidate a freshly created connection); no-op when no connection is cached.
ServiceBusSenderAsyncClientTest: Updated failedSendMessageReportsMetrics to use a FATAL error (the broadened retry filter would otherwise retry on the previous test error).
All existing tests pass: 638 (core-amqp) + 941 (servicebus) = 1579 tests, 0 failures.

Cross-SDK parity

Feature	Go	.NET	Python	JS	Java (this PR)
Error classification	`GetRecoveryKind()`	`HasLinkCommunicationError`	`shutdown_handler`	Event-driven	`RecoveryKind.classify()`
Link recovery	Close link + session	`FaultTolerantAmqpObject`	Close handler	`closeLink()`	`closeAsync()` + `removeSession()`
Connection recovery	`Namespace.Recover()`	`ActiveConnection.GetOrCreateAsync`	Close handler + reopen	`refreshConnection()`	`invalidateConnection()` (target-id keyed)
Recovery composition	Inline at call site	Lazy detect on next op	Between retries	Event-driven	`onErrorResume(recoverBeforeRetry)` before re-emit

Related issues

Directly fixes or would have prevented:

[BUG] Servicebus-Java ''Timeout on blocking read' when sending messages' #44688 — Timeout on blocking read when sending (OPEN)
ServiceBus Client is not surfacing connection errors #39154 — Connection errors not surfaced
[BUG] Message sending in ServiceBus queue occasionally fails with error "Cannot send a message when request response channel is disposed" or "Timeout on blocking read" #43877 — "Cannot send when request response channel disposed"
[BUG] Message sending not retried after blocking timeout expired #43830 — Send not retried after blocking timeout
[BUG] Service Bus retry functionality not working as expected #43842 — Retry functionality not working as expected
[BUG] Encounter Timeout exception constantly while accessing service bus with ServiceBusSenderClient #34003 — Constant timeout exceptions sending
[BUG] Transient error occurred: The link '...' is force detached #34588 — "Link force detached" transient error
[BUG] Service Bus Session Processor stop receiving messages, because if the pending attach link is forced to close without any errors, it cannot be recovered. #33313 — Session processor stops, link force-closed without error
[BUG] Topic subscription randomly stops consuming messages after likely initial connection loss #40608 — Topic subscription stops consuming after connection loss
[BUG] : sudden cessation of message consumption using ServiceBusProcessorClient in multiple Java applications #40496 — Sudden cessation of message consumption
[BUG] azure-messaging-servicebus:7.15.1 - Application not consume any message from Azure Service Bus after logs "The connection was closed by container because it did not have any active links in the past 300000 milliseconds" printed on AKS #41489 — App stops consuming after "no active links in 300000ms"
[BUG] ServiceBusReceiverClient client never returning after receiveMessages method call (maxWaitTime is set to 1 sec) #37594 — ReceiverClient never returns from receiveMessages
[BUG] Service Bus SDK hangs processing multiple sessions #37272 — SDK hangs processing multiple sessions
[BUG] ServiceBus: retry com.microsoft:operation-cancelled errors #35511 — Retry operation-cancelled errors
[BUG] Sporadic timeouts sending to service bus with azure-messaging-servicebus #24500 — Sporadic send timeouts
[BUG] Event Hub and Service Bus Producers should attempt to create a connection on send #27520 — Producers should create connection on send
Receive message connection from ServiceBusProcessorClient closes due to inactivity in service bus #40805 — Processor connection closes due to inactivity
Cannot publish message when disposed (AmqpMessagePublisher.IdleTimerExpired) #35193 — Cannot publish when disposed (IdleTimerExpired)

Add RecoveryKind error classification and recovery-aware retry to azure-core-amqp. Apply tiered recovery to all Service Bus sender, receiver, and session paths. On LINK errors: dispose stale link/session, retry with fresh resources. On CONNECTION errors: force-close the cached connection, retry with fresh connection. Includes quick-retry optimization and didQuickRetry deduplication. Fixes Azure#44688

Copilot

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Add azure-core-amqp to AdditionalModules in ci.yml and trigger paths so CI builds it from source alongside servicebus. Update pom.xml to reference 2.12.0-beta.1 with current tag (cross-module PR -- to be revisited after azure-core-amqp is released to Maven Central). Note: uses current tag temporarily; reviewer to confirm release sequencing.

Copilot

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Copilot

Pull request overview

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

You can also share your feedback on Copilot code review. Take the survey.

Address 6 comments from Copilot PR review on Azure#48460: - sendFluxInternal: wrap only batchList (link acquisition) with withRetryAndRecovery, not the full sendOperation. Wrapping the outer operation caused the user-provided Flux to be re-subscribed on each retry and nested retries with sendBatchInternal. - scheduleMessageInternal: change getSendLink to getSendLinkWithRetry so schedule operations get the same tiered recovery as other send paths. - ReactorConnectionCache.forceCloseConnection: use connection.dispose() instead of closeAsync() so isDisposed() returns true synchronously. This ensures cacheInvalidateIf invalidates the cached reference immediately on the next get() call. - RetryUtil: replace Math.random() with ThreadLocalRandom.current() to eliminate shared RNG contention and improve testability. - performRecovery comment: remove contradictory 'happens organically' comment that conflicted with the explicit forceCloseConnection() call. - ServiceBusReceiverAsyncClient: add error handler to the subscribe() call inside the LINK recovery callback so failures are logged and do not silently leak.

Copilot

Pull request overview

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

You can also share your feedback on Copilot code review. Take the survey.

- T1: ServiceBusSessionAcquirer - return delay after forceCloseConnection for RecoveryKind.CONNECTION so session acquisition retries after connection recovery - T2: ServiceBusSessionManager - merge LINK and CONNECTION into a single delay branch so CONNECTION errors retry instead of falling through to publishError - T3: ServiceBusSenderAsyncClient - narrow withRetryAndRecovery to wrap only link acquisition (getSendLink); messages.collect() moved outside retry boundary to avoid re-subscribing user Flux on retry - T4: RecoveryKind - reclassify OPERATION_CANCELLED from NONE to LINK because core-amqp raises it when AMQP layer unexpectedly aborts or disconnects, which requires link recovery (e.g. ReceiverUnsettledDeliveries remote Released outcome) - T5: RecoveryKind - reclassify RESOURCE_LIMIT_EXCEEDED from FATAL to NONE to match ReactorSender.isGeneralSendError() which treats it as retriable alongside SERVER_BUSY and TIMEOUT - T6: RetryUtilTest - add four tests for createRetryWithRecovery covering FATAL no-retry, LINK recovery callback, CONNECTION recovery callback, and retry budget exhaustion; use virtual time for backoff-delay scenarios - T7: RecoveryKindTest - rename operationCancelled test to expect LINK result, add new test asserting RESOURCE_LIMIT_EXCEEDED classifies as NONE

Copilot

Pull request overview

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

You can also share your feedback on Copilot code review. Take the survey.

- T8: RetryUtil - clamp final jittered delay to maxDelay so retryOptions are consistently respected. Previously jitter was applied after the pre-jitter cap which could produce a delay exceeding retryOptions.getMaxDelay(). Also cap baseDelay to maxDelay in FIXED mode (FIXED previously used baseDelay without checking against maxDelay, unlike the EXPONENTIAL path). - T9: ServiceBusReceiverAsyncClient - fix misleading log message in the LINK/ CONNECTION recovery callback. The error handler on connectionProcessor.subscribe fires only when obtaining the connection fails (not when removeSession fails, since it returns a boolean). Renamed to "Error obtaining connection during {} recovery." Also log the boolean result of removeSession at VERBOSE level to confirm whether a stale session was actually evicted.

Copilot

Pull request overview

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

You can also share your feedback on Copilot code review. Take the survey.

…overy T10: In ServiceBusSenderAsyncClient.performRecovery(), replace link.dispose() with link.closeAsync().subscribe(...). ReactorSender.dispose() calls closeAsync().block(tryTimeout), which blocks the Reactor thread when invoked from a recovery callback on a non-blocking scheduler. T11: In ReactorConnectionCache.forceCloseConnection(), replace connection.dispose() with a non-blocking equivalent: set a new forceInvalidate AtomicBoolean flag before starting connection.closeAsync().subscribe(...). The cacheInvalidateIf predicate now checks forceInvalidate in addition to isDisposed(), ensuring the cache is invalidated synchronously (by the flag) while the close handshake completes asynchronously. ReactorConnection.dispose() has the same blocking pattern. T12: Update comment in RetryUtil.createRetryWithRecovery() to remove the misleading claim that the quick-retry path matches Go's ResetAttempts(). The Java implementation uses a didQuickRetry flag only (no attempt counter reset); subsequent retries continue standard exponential backoff from the running count.

This PR adds new azure-core-amqp API consumed by azure-messaging-servicebus, so the two libraries co-release in the same pipeline. The servicebus POM must reference azure-core-amqp via the current version tag (2.13.0-beta.1), not the dependency tag (released 2.12.0). With the dependency tag, the version scanner failed ("incorrectly set to dependency") and non-From-Source CI builds could not resolve the new symbols ("cannot find symbol"), cascading to all Build/Test/Analyze/APIView jobs.

Eldert Grootenboer (EldertGrootenboer) · 2026-07-10T23:07:28Z

Copilot resolve the merge conflicts in this pull request

…-send-recovery # Conflicts: # sdk/servicebus/azure-messaging-servicebus/src/main/java/com/azure/messaging/servicebus/ServiceBusSenderAsyncClient.java

…-send-recovery # Conflicts: # sdk/servicebus/azure-messaging-servicebus/src/main/java/com/azure/messaging/servicebus/ServiceBusSessionAcquirer.java

Copilot

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 1 comment.

- Wraps a 125-char comment onto two lines to stay within the repo's 120-char convention.

Copilot

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 1 comment.

…backoff - Adds a retryBackoff field to ServiceBusSessionManager, derived from AmqpRetryOptions.getDelay() with a 100ms fallback, matching ServiceBusSessionAcquirer. - The LINK/CONNECTION retry branch now delays by that backoff instead of Duration.ZERO, so a link that repeatedly detaches quickly no longer spins the retry loop.

Copilot

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated no new comments.

Eldert Grootenboer (EldertGrootenboer) · 2026-08-26T15:42:15Z

Copilot resolve the merge conflicts in this pull request

…-send-recovery # Conflicts: # sdk/servicebus/azure-messaging-servicebus/pom.xml

Sunghyun Jung (sunghyun1999) · 2026-09-17T04:18:57Z

Hi — I filed #50503 with a production case that this PR's recovery mechanism would not cover.

The gap: RecoveryKind.classify() returns NONE for TimeoutException, assuming the link is still healthy. However, when a sender link is silently detached (e.g., by LB/NAT idle timeout on Kubernetes), the link is functionally dead but remains cached in ReactorSession.openSendLinks. Every send attempt hangs until tryTimeout, producing a TimeoutException — but the root cause is a dead link, not a transient delay.

In our production incident:

Same AMQP connection, two queues: queue-a (dead link) → 10/10 failures over 25 hours; queue-b (healthy link) → 8/8 successes in 12–33ms
A fresh pod sent to queue-a successfully in 87.8ms at the same time — confirming Azure service was healthy
The only fix was JVM restart

Since the error surfaced to RecoveryKind.classify() is TimeoutException, the new recoverBeforeRetry() path returns Mono.empty() and the dead link is reused on every retry.

Possible approach: Track consecutive timeouts per link. After N consecutive TimeoutExceptions on the same link (e.g., 2), escalate from NONE to LINK — close the cached link and let the next retry create a fresh one. A single timeout stays NONE (preserving the "link may still be healthy" assumption for transient cases), but repeated timeouts strongly indicate a dead link.

Alternatively, adding a liveness check in ReactorSession.openSendLinks cache lookup (checking link.isDisposed() or similar) would catch this at the source regardless of error classification.

See #50503 for the full evidence and timeline.

Eldert Grootenboer (EldertGrootenboer) · 2026-10-28T20:15:34Z

The disposed-link cache check stays in Azure/azure-sdk-for-java#50505 - Add liveness check for cached AMQP links in ReactorSession, and TimeoutException stays classified as NONE in this PR.
That check covers links marked disposed, not a silently dead link that still reports isDisposed() == false.

The timeout-only case stays tracked in Azure/azure-sdk-for-java#50503 - ServiceBusSenderClient permanently stuck when a single AMQP sender link is detached, with separate validation needed before adding repeated-timeout escalation.

- Use the co-built azure-core-amqp version and current marker. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

- Use azure-core 1.61.0 for the HTTP Netty 1.17.0 test transport. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot

🟡 Changes recommended

Recovery handling can make named-session acquisition retry indefinitely and let delayed errors evict healthy replacement connections, while several send-failure paths still bypass recovery.

5 open issues

_{Review effort: Balanced}

- Target connection recovery and cleanup to the failed operation - Preserve terminal session errors and recover aborted sends - Normalize negotiation failures and refresh unnamed session links - Cover stale callbacks, delayed errors, and non-completing close Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot

🔵 Needs a closer look

Human assessment is needed for interacting recovery and cleanup paths, particularly where a stalled close can leave a disposed sender cached for subsequent sends.

No open issues 🎉

5 resolved since last review

_{Review effort: Balanced}

Copilot

🟡 Changes recommended

Unresolved recovery defects can reuse stale sessions or disposed senders, leak half-open links, reconnect without backoff, and reject intended resource-limit retries.

5 open issues

_{Review effort: Balanced}

- Retry resource-limit failures without closing healthy resources - Normalize cross-entity session eviction and honor connection backoff - Close abandoned session links asynchronously on timeout or cancellation - Cover failure paths and preserve terminal error handling Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot

🟡 Changes recommended

Critical LINK recovery issues can permanently stall sends by retaining a disposed sender and close a healthy replacement session through name-only eviction.

1 open issue

Prevent delayed LINK recovery from removing replacement sessions · New

5 resolved since last review

_{Review effort: Balanced}

- Evict only the session owned by a failed receive-link attempt - Guard session cache cleanup against delayed callbacks and open failures - Cover both receive factories, cache backends and cross-entity keys Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

- Allow Mockito reflection in the modular Java test JVM - Keep production module exports and recovery behavior unchanged Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings March 18, 2026 03:10

Eldert Grootenboer (EldertGrootenboer) requested review from a team, Anu Thomas (anuchandy), Connie Yau (conniey) and Srini Karri (skarri-microsoft) as code owners March 18, 2026 03:10

github-actions Bot added Azure.Core.AMQP azure-core-amqp Service Bus labels Mar 18, 2026

Copilot started reviewing on behalf of Eldert Grootenboer (EldertGrootenboer) March 18, 2026 03:11

View session

Copilot AI reviewed Mar 18, 2026

Eldert Grootenboer (EldertGrootenboer) requested a review from Copilot March 18, 2026 04:12

Merge branch 'main' into fix/servicebus-tiered-send-recovery

f0c6e53

Copilot started reviewing on behalf of Eldert Grootenboer (EldertGrootenboer) March 18, 2026 04:13

View session

Copilot AI reviewed Mar 18, 2026

Eldert Grootenboer (EldertGrootenboer) requested a review from Copilot March 18, 2026 14:37

Merge branch 'main' into fix/servicebus-tiered-send-recovery

0bd7282

Copilot started reviewing on behalf of Eldert Grootenboer (EldertGrootenboer) March 18, 2026 14:40

View session

Copilot AI reviewed Mar 18, 2026

View reviewed changes

Eldert Grootenboer (EldertGrootenboer) requested a review from Copilot March 18, 2026 17:52

Copilot started reviewing on behalf of Eldert Grootenboer (EldertGrootenboer) March 18, 2026 17:53

View session

Copilot AI reviewed Mar 18, 2026

View reviewed changes

Eldert Grootenboer (EldertGrootenboer) requested a review from Copilot March 18, 2026 20:28

Copilot AI reviewed Mar 18, 2026

View reviewed changes

Comment thread sdk/core/azure-core-amqp/src/main/java/com/azure/core/amqp/implementation/RetryUtil.java Outdated

Comment thread ...g-servicebus/src/main/java/com/azure/messaging/servicebus/ServiceBusReceiverAsyncClient.java Outdated

Eldert Grootenboer (EldertGrootenboer) requested a review from Copilot March 18, 2026 20:47

Copilot AI reviewed Mar 18, 2026

View reviewed changes

EldertGrootenboerMS and others added 2 commits June 17, 2026 16:32

Merge branch 'main' into fix/servicebus-tiered-send-recovery

d8f7153

Eldert Grootenboer (EldertGrootenboer) added 3 commits July 10, 2026 17:11

Merge remote-tracking branch 'origin/main' into fix/servicebus-tiered…

abb8ee4

…-send-recovery # Conflicts: # sdk/servicebus/azure-messaging-servicebus/src/main/java/com/azure/messaging/servicebus/ServiceBusSenderAsyncClient.java

Apply spotless formatting to ServiceBusSenderAsyncClient

4961959

Merge remote-tracking branch 'origin/main' into fix/servicebus-tiered…

1c1a60d

…-send-recovery # Conflicts: # sdk/servicebus/azure-messaging-servicebus/src/main/java/com/azure/messaging/servicebus/ServiceBusSessionAcquirer.java

Copilot AI reviewed Jul 27, 2026

View reviewed changes

Comment thread sdk/core/azure-core-amqp/src/test/java/com/azure/core/amqp/implementation/RecoveryKindTest.java Outdated

style: wrap over-length comment in RecoveryKindTest

8302361

- Wraps a 125-char comment onto two lines to stay within the repo's 120-char convention.

Copilot AI reviewed Jul 27, 2026

View reviewed changes

Comment thread ...saging-servicebus/src/main/java/com/azure/messaging/servicebus/ServiceBusSessionManager.java Outdated

Copilot AI reviewed Jul 27, 2026

View reviewed changes

Merge branch 'main' into fix/servicebus-tiered-send-recovery

017b846

Merge remote-tracking branch 'origin/main' into fix/servicebus-tiered…

bd7ef4e

…-send-recovery # Conflicts: # sdk/servicebus/azure-messaging-servicebus/pom.xml

Sunghyun Jung (sunghyun1999) mentioned this pull request Sep 17, 2026

[BUG] ServiceBusSenderClient permanently stuck when a single AMQP sender link is detached — dead link cached in ReactorSession.openSendLinks #50503

Open

3 tasks done

Sunghyun Jung (sunghyun1999) mentioned this pull request Sep 17, 2026

Add liveness check for cached AMQP links in ReactorSession #50505

Open

1 of 3 tasks

Eldert Grootenboer (EldertGrootenboer) and others added 3 commits October 28, 2026 13:19

Merge branch 'main' into fix/servicebus-tiered-send-recovery

b7b01db

fix: restore in-flight AMQP dependency for tiered recovery

e6c96e0

- Use the co-built azure-core-amqp version and current marker. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

fix: align management playback with supported azure-core

46f8acc

- Use azure-core 1.61.0 for the HTTP Netty 1.17.0 test transport. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot AI reviewed Oct 29, 2026

View reviewed changes

Merge branch 'main' into fix/servicebus-tiered-send-recovery

d797c09

Copilot AI reviewed Oct 29, 2026

View reviewed changes

Comment thread ...g-servicebus/src/main/java/com/azure/messaging/servicebus/ServiceBusReceiverAsyncClient.java Outdated

Eldert Grootenboer (EldertGrootenboer) and others added 2 commits October 29, 2026 14:58

test: open AMQP internals to Service Bus recovery tests

6ede6b3

- Allow Mockito reflection in the modular Java test JVM - Keep production module exports and recovery behavior unchanged Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Conversation

Eldert Grootenboer (EldertGrootenboer) commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this PR does

Changes

azure-core-amqp (shared — benefits Event Hubs too)

azure-messaging-servicebus

Tests

Cross-SDK parity

Related issues

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Eldert Grootenboer (EldertGrootenboer) commented Jul 10, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Eldert Grootenboer (EldertGrootenboer) commented Aug 26, 2026

Uh oh!

Sunghyun Jung (sunghyun1999) commented Sep 17, 2026

Uh oh!

Eldert Grootenboer (EldertGrootenboer) commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Uh oh!

Eldert Grootenboer (EldertGrootenboer) commented Mar 18, 2026 •

edited

Loading

Eldert Grootenboer (EldertGrootenboer) commented Oct 28, 2026 •

edited

Loading