upstream: coalesce load balancer rebuilds during batch host updates by wdauchy · Pull Request #43346 · envoyproxy/envoy

wdauchy · 2026-02-05T13:29:05Z

Commit Message:
During EDS batch updates that modify multiple priorities, all load
balancers in the inheritance chain (LoadBalancerBase, ZoneAwareLoadBalancerBase,
EdfLoadBalancerBase) do expensive per-priority work for every individual
priority update via PriorityUpdateCb. This includes:

LoadBalancerBase: recalculating per-priority health state and panic mode
ZoneAwareLoadBalancerBase: rebuilding locality-weighted routing structures
EdfLoadBalancerBase: rebuilding EDF schedulers at O(n log n) per HostsSource

For clusters with ~5k endpoints undergoing bulk IP changes during rollouts,
this causes significant CPU spikes on the main thread as each priority
update triggers redundant recalculations across the full LB stack.

The fix leverages the existing MemberUpdateCb which fires once after the
entire batch completes (unlike PriorityUpdateCb which fires per priority).
Instead of doing work immediately in PriorityUpdateCb, each LB level now
marks the priority as dirty. The actual work happens in MemberUpdateCb,
coalescing all dirty priorities into a single pass.

ThreadAwareLoadBalancerBase (used by RingHash and Maglev) is also updated
to call refresh() from MemberUpdateCb instead of PriorityUpdateCb, ensuring
it reads per-priority state after LoadBalancerBase has processed dirty
priorities.

Additionally, MockPrioritySet callback ordering is fixed to match real
PrioritySetImpl behavior (PriorityUpdateCb fires before MemberUpdateCb).

Additional Description:
Risk Level: medium
Testing: unit tests updated, new test for batch callback behavior
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

repokitteh-read-only · 2026-02-05T13:29:11Z

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #43346 was opened by wdauchy.

see: more, trace.

During EDS batch updates that modify multiple priorities, all load balancers in the inheritance chain (LoadBalancerBase, ZoneAwareLoadBalancerBase, EdfLoadBalancerBase) do expensive per-priority work for every individual priority update via PriorityUpdateCb. This includes: - LoadBalancerBase: recalculating per-priority health state and panic mode - ZoneAwareLoadBalancerBase: rebuilding locality-weighted routing structures - EdfLoadBalancerBase: rebuilding EDF schedulers at O(n log n) per HostsSource For clusters with ~5k endpoints undergoing bulk IP changes during rollouts, this causes significant CPU spikes on the main thread as each priority update triggers redundant recalculations across the full LB stack. The fix leverages the existing MemberUpdateCb which fires once after the entire batch completes (unlike PriorityUpdateCb which fires per priority). Instead of doing work immediately in PriorityUpdateCb, each LB level now marks the priority as dirty. The actual work happens in MemberUpdateCb, coalescing all dirty priorities into a single pass. Signed-off-by: William Dauchy <william.dauchy@datadoghq.com>

botengyao · 2026-02-18T18:16:20Z

Hi @nezdolik, could we borrow some your EDS expertise for this PR's review as well? Thanks!

wdauchy · 2026-02-19T12:14:25Z

/retest transients

wdauchy · 2026-02-20T08:40:25Z

/retest transients

wdauchy · 2026-02-20T14:13:36Z

/retest transients

wdauchy · 2026-02-20T15:42:29Z

/retest transients

wdauchy · 2026-02-20T19:15:35Z

/retest transients

botengyao

lgtm in high level, thanks for the improvment!

Merging main will pass the CI, also could you also add a changelog?

/wait

botengyao · 2026-02-22T06:17:52Z

-  priority_update_cb_ = priority_set_.addPriorityUpdateCb(
-      [this](uint32_t, const HostVector&, const HostVector&) { refresh(); });
+  member_update_cb_ =
+      priority_set_.addMemberUpdateCb([this](const HostVector&, const HostVector&) { refresh(); });


refresh() reads per_priority_load_ and per_priority_panic_ from LoadBalancerBase. So there are 2 callbacks that are in order, but it could break for future's refactor. Could we make this ordering-independent by pulling the dirty-priority processing into a protected idempotent helper, and calling it both from both?

good point, you're right that relying on callback registration order is fragile. I've added a processDirtyPriorities() protected method on LoadBalancerBase that's idempotent (no-op if dirty set is empty). ThreadAwareLoadBalancerBase now calls it before refresh() in its own MemberUpdateCb, so even if the ordering changes in a future refactor, it will always have up-to-date per_priority_load_ and per_priority_panic_ state.

botengyao · 2026-02-22T06:19:46Z

-                                    total_healthy_hosts_);
-        recalculatePerPriorityPanic();
-        stashed_random_.clear();
+        dirty_priorities_.insert(priority);


I would suggest adding a runtime guard for this.

done, added envoy.reloadable_features.coalesce_lb_rebuilds_on_batch_update with a changelog entry. when the guard is off, the original behavior is preserved (work done inline in PriorityUpdateCb). the flag is checked once at LB construction time so there's no per-update overhead.

wdauchy · 2026-02-22T14:12:03Z

/retest transients

Signed-off-by: William Dauchy <william.dauchy@datadoghq.com>

repokitteh-read-only · 2026-02-22T15:16:17Z

CC @envoyproxy/coverage-shephards: FYI only for changes made to (test/coverage.yaml).
envoyproxy/coverage-shephards assignee is @RyanTheOptimist

🐱

Caused by: #43346 was synchronize by wdauchy.

see: more, trace.

wdauchy · 2026-02-22T16:25:32Z

/retest transients

botengyao

lgtm in high level, thanks for the great contribution!

botengyao · 2026-02-22T20:22:19Z

  source/extensions/internal_redirect/safe_cross_scheme: 81.3
  source/extensions/internal_redirect/allow_listed_routes: 85.7
  source/extensions/internal_redirect/previous_routes: 89.3
-  source/extensions/load_balancing_policies/common: 96.3


what can we do to fill the 0.3?

for this patch I honestly don't know, that's why I ended up doing this. I think load balancing policies could deserve more tests, but do we want to add them in this pr?

ok I will try a last stretch

now fixed, sorry for the lazyness I had earlier :))

Signed-off-by: William Dauchy <william.dauchy@datadoghq.com>

nezdolik

Thanks for great improvement, had just one question

nezdolik · 2026-02-23T10:28:22Z

-        }
-
-        if (locality_weighted_balancing_) {
-          rebuildLocalityWrrForPriority(priority);


is there any co-dependency between regenerateLocalityRoutingStructures() and rebuildLocalityWrrForPriority() in order of invocation? E.g. in original code regenerateLocalityRoutingStructures() is invoked before rebuildLocalityWrrForPriority().

good catch. there's no data co-dependency between the two, regenerateLocalityRoutingStructures() writes to locality_routing_state_/residual_capacity_ while rebuildLocalityWrrForPriority() writes to locality_wrr_, so they don't read each other's output. that said, you're right the original code had regenerateLocalityRoutingStructures() first, so I've restored that ordering in both the new and fallback paths to stay consistent with the original behavior.

Signed-off-by: William Dauchy <william.dauchy@datadoghq.com>

botengyao

lgtm, thanks!

…43697) Fixes a crash introduced by #43346. When a thread-aware load balancer is initialized mid-batch, the per-priority panic tracking vectors have not been resized yet because the batch member update callback hasn't fired. This causes an out-of-bounds read during the LB refresh loop. 1. Process any dirty priorities to properly size vectors if the load balancer is initialized mid-batch. 2. Add a bounds check `ASSERT` to prevent silent out-of-bounds bit vector reads. 3. Add an initialization regression test to prevent this pattern from breaking in the future. Commit Message: Additional Description: Risk Level: low (already guarded by `envoy.reloadable_features.coalesce_lb_rebuilds_on_batch_update`). Testing: Docs Changes: Release Notes: Signed-off-by: Boteng Yao <boteng@google.com>

…nvoyproxy#43346) Commit Message: During EDS batch updates that modify multiple priorities, all load balancers in the inheritance chain (LoadBalancerBase, ZoneAwareLoadBalancerBase, EdfLoadBalancerBase) do expensive per-priority work for every individual priority update via PriorityUpdateCb. This includes: - LoadBalancerBase: recalculating per-priority health state and panic mode - ZoneAwareLoadBalancerBase: rebuilding locality-weighted routing structures - EdfLoadBalancerBase: rebuilding EDF schedulers at O(n log n) per HostsSource For clusters with ~5k endpoints undergoing bulk IP changes during rollouts, this causes significant CPU spikes on the main thread as each priority update triggers redundant recalculations across the full LB stack. The fix leverages the existing MemberUpdateCb which fires once after the entire batch completes (unlike PriorityUpdateCb which fires per priority). Instead of doing work immediately in PriorityUpdateCb, each LB level now marks the priority as dirty. The actual work happens in MemberUpdateCb, coalescing all dirty priorities into a single pass. ThreadAwareLoadBalancerBase (used by RingHash and Maglev) is also updated to call refresh() from MemberUpdateCb instead of PriorityUpdateCb, ensuring it reads per-priority state after LoadBalancerBase has processed dirty priorities. Additionally, MockPrioritySet callback ordering is fixed to match real PrioritySetImpl behavior (PriorityUpdateCb fires before MemberUpdateCb). Additional Description: Risk Level: medium Testing: unit tests updated, new test for batch callback behavior Docs Changes: n/a Release Notes: n/a Platform Specific Features: n/a [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: William Dauchy <william.dauchy@datadoghq.com> Signed-off-by: bjmask <11672696+bjmask@users.noreply.github.com>

…nvoyproxy#43697) Fixes a crash introduced by envoyproxy#43346. When a thread-aware load balancer is initialized mid-batch, the per-priority panic tracking vectors have not been resized yet because the batch member update callback hasn't fired. This causes an out-of-bounds read during the LB refresh loop. 1. Process any dirty priorities to properly size vectors if the load balancer is initialized mid-batch. 2. Add a bounds check `ASSERT` to prevent silent out-of-bounds bit vector reads. 3. Add an initialization regression test to prevent this pattern from breaking in the future. Commit Message: Additional Description: Risk Level: low (already guarded by `envoy.reloadable_features.coalesce_lb_rebuilds_on_batch_update`). Testing: Docs Changes: Release Notes: Signed-off-by: Boteng Yao <boteng@google.com> Signed-off-by: bjmask <11672696+bjmask@users.noreply.github.com>

…nvoyproxy#43346) Commit Message: During EDS batch updates that modify multiple priorities, all load balancers in the inheritance chain (LoadBalancerBase, ZoneAwareLoadBalancerBase, EdfLoadBalancerBase) do expensive per-priority work for every individual priority update via PriorityUpdateCb. This includes: - LoadBalancerBase: recalculating per-priority health state and panic mode - ZoneAwareLoadBalancerBase: rebuilding locality-weighted routing structures - EdfLoadBalancerBase: rebuilding EDF schedulers at O(n log n) per HostsSource For clusters with ~5k endpoints undergoing bulk IP changes during rollouts, this causes significant CPU spikes on the main thread as each priority update triggers redundant recalculations across the full LB stack. The fix leverages the existing MemberUpdateCb which fires once after the entire batch completes (unlike PriorityUpdateCb which fires per priority). Instead of doing work immediately in PriorityUpdateCb, each LB level now marks the priority as dirty. The actual work happens in MemberUpdateCb, coalescing all dirty priorities into a single pass. ThreadAwareLoadBalancerBase (used by RingHash and Maglev) is also updated to call refresh() from MemberUpdateCb instead of PriorityUpdateCb, ensuring it reads per-priority state after LoadBalancerBase has processed dirty priorities. Additionally, MockPrioritySet callback ordering is fixed to match real PrioritySetImpl behavior (PriorityUpdateCb fires before MemberUpdateCb). Additional Description: Risk Level: medium Testing: unit tests updated, new test for batch callback behavior Docs Changes: n/a Release Notes: n/a Platform Specific Features: n/a [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: William Dauchy <william.dauchy@datadoghq.com>

…nvoyproxy#43697) Fixes a crash introduced by envoyproxy#43346. When a thread-aware load balancer is initialized mid-batch, the per-priority panic tracking vectors have not been resized yet because the batch member update callback hasn't fired. This causes an out-of-bounds read during the LB refresh loop. 1. Process any dirty priorities to properly size vectors if the load balancer is initialized mid-batch. 2. Add a bounds check `ASSERT` to prevent silent out-of-bounds bit vector reads. 3. Add an initialization regression test to prevent this pattern from breaking in the future. Commit Message: Additional Description: Risk Level: low (already guarded by `envoy.reloadable_features.coalesce_lb_rebuilds_on_batch_update`). Testing: Docs Changes: Release Notes: Signed-off-by: Boteng Yao <boteng@google.com>

…nvoyproxy#43346) Commit Message: During EDS batch updates that modify multiple priorities, all load balancers in the inheritance chain (LoadBalancerBase, ZoneAwareLoadBalancerBase, EdfLoadBalancerBase) do expensive per-priority work for every individual priority update via PriorityUpdateCb. This includes: - LoadBalancerBase: recalculating per-priority health state and panic mode - ZoneAwareLoadBalancerBase: rebuilding locality-weighted routing structures - EdfLoadBalancerBase: rebuilding EDF schedulers at O(n log n) per HostsSource For clusters with ~5k endpoints undergoing bulk IP changes during rollouts, this causes significant CPU spikes on the main thread as each priority update triggers redundant recalculations across the full LB stack. The fix leverages the existing MemberUpdateCb which fires once after the entire batch completes (unlike PriorityUpdateCb which fires per priority). Instead of doing work immediately in PriorityUpdateCb, each LB level now marks the priority as dirty. The actual work happens in MemberUpdateCb, coalescing all dirty priorities into a single pass. ThreadAwareLoadBalancerBase (used by RingHash and Maglev) is also updated to call refresh() from MemberUpdateCb instead of PriorityUpdateCb, ensuring it reads per-priority state after LoadBalancerBase has processed dirty priorities. Additionally, MockPrioritySet callback ordering is fixed to match real PrioritySetImpl behavior (PriorityUpdateCb fires before MemberUpdateCb). Additional Description: Risk Level: medium Testing: unit tests updated, new test for batch callback behavior Docs Changes: n/a Release Notes: n/a Platform Specific Features: n/a [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: William Dauchy <william.dauchy@datadoghq.com>

…nvoyproxy#43697) Fixes a crash introduced by envoyproxy#43346. When a thread-aware load balancer is initialized mid-batch, the per-priority panic tracking vectors have not been resized yet because the batch member update callback hasn't fired. This causes an out-of-bounds read during the LB refresh loop. 1. Process any dirty priorities to properly size vectors if the load balancer is initialized mid-batch. 2. Add a bounds check `ASSERT` to prevent silent out-of-bounds bit vector reads. 3. Add an initialization regression test to prevent this pattern from breaking in the future. Commit Message: Additional Description: Risk Level: low (already guarded by `envoy.reloadable_features.coalesce_lb_rebuilds_on_batch_update`). Testing: Docs Changes: Release Notes: Signed-off-by: Boteng Yao <boteng@google.com>

…nvoyproxy#43346) Commit Message: During EDS batch updates that modify multiple priorities, all load balancers in the inheritance chain (LoadBalancerBase, ZoneAwareLoadBalancerBase, EdfLoadBalancerBase) do expensive per-priority work for every individual priority update via PriorityUpdateCb. This includes: - LoadBalancerBase: recalculating per-priority health state and panic mode - ZoneAwareLoadBalancerBase: rebuilding locality-weighted routing structures - EdfLoadBalancerBase: rebuilding EDF schedulers at O(n log n) per HostsSource For clusters with ~5k endpoints undergoing bulk IP changes during rollouts, this causes significant CPU spikes on the main thread as each priority update triggers redundant recalculations across the full LB stack. The fix leverages the existing MemberUpdateCb which fires once after the entire batch completes (unlike PriorityUpdateCb which fires per priority). Instead of doing work immediately in PriorityUpdateCb, each LB level now marks the priority as dirty. The actual work happens in MemberUpdateCb, coalescing all dirty priorities into a single pass. ThreadAwareLoadBalancerBase (used by RingHash and Maglev) is also updated to call refresh() from MemberUpdateCb instead of PriorityUpdateCb, ensuring it reads per-priority state after LoadBalancerBase has processed dirty priorities. Additionally, MockPrioritySet callback ordering is fixed to match real PrioritySetImpl behavior (PriorityUpdateCb fires before MemberUpdateCb). Additional Description: Risk Level: medium Testing: unit tests updated, new test for batch callback behavior Docs Changes: n/a Release Notes: n/a Platform Specific Features: n/a [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: William Dauchy <william.dauchy@datadoghq.com>

…nvoyproxy#43697) Fixes a crash introduced by envoyproxy#43346. When a thread-aware load balancer is initialized mid-batch, the per-priority panic tracking vectors have not been resized yet because the batch member update callback hasn't fired. This causes an out-of-bounds read during the LB refresh loop. 1. Process any dirty priorities to properly size vectors if the load balancer is initialized mid-batch. 2. Add a bounds check `ASSERT` to prevent silent out-of-bounds bit vector reads. 3. Add an initialization regression test to prevent this pattern from breaking in the future. Commit Message: Additional Description: Risk Level: low (already guarded by `envoy.reloadable_features.coalesce_lb_rebuilds_on_batch_update`). Testing: Docs Changes: Release Notes: Signed-off-by: Boteng Yao <boteng@google.com>

…nvoyproxy#43346) Commit Message: During EDS batch updates that modify multiple priorities, all load balancers in the inheritance chain (LoadBalancerBase, ZoneAwareLoadBalancerBase, EdfLoadBalancerBase) do expensive per-priority work for every individual priority update via PriorityUpdateCb. This includes: - LoadBalancerBase: recalculating per-priority health state and panic mode - ZoneAwareLoadBalancerBase: rebuilding locality-weighted routing structures - EdfLoadBalancerBase: rebuilding EDF schedulers at O(n log n) per HostsSource For clusters with ~5k endpoints undergoing bulk IP changes during rollouts, this causes significant CPU spikes on the main thread as each priority update triggers redundant recalculations across the full LB stack. The fix leverages the existing MemberUpdateCb which fires once after the entire batch completes (unlike PriorityUpdateCb which fires per priority). Instead of doing work immediately in PriorityUpdateCb, each LB level now marks the priority as dirty. The actual work happens in MemberUpdateCb, coalescing all dirty priorities into a single pass. ThreadAwareLoadBalancerBase (used by RingHash and Maglev) is also updated to call refresh() from MemberUpdateCb instead of PriorityUpdateCb, ensuring it reads per-priority state after LoadBalancerBase has processed dirty priorities. Additionally, MockPrioritySet callback ordering is fixed to match real PrioritySetImpl behavior (PriorityUpdateCb fires before MemberUpdateCb). Additional Description: Risk Level: medium Testing: unit tests updated, new test for batch callback behavior Docs Changes: n/a Release Notes: n/a Platform Specific Features: n/a [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: William Dauchy <william.dauchy@datadoghq.com>

…nvoyproxy#43697) Fixes a crash introduced by envoyproxy#43346. When a thread-aware load balancer is initialized mid-batch, the per-priority panic tracking vectors have not been resized yet because the batch member update callback hasn't fired. This causes an out-of-bounds read during the LB refresh loop. 1. Process any dirty priorities to properly size vectors if the load balancer is initialized mid-batch. 2. Add a bounds check `ASSERT` to prevent silent out-of-bounds bit vector reads. 3. Add an initialization regression test to prevent this pattern from breaking in the future. Commit Message: Additional Description: Risk Level: low (already guarded by `envoy.reloadable_features.coalesce_lb_rebuilds_on_batch_update`). Testing: Docs Changes: Release Notes: Signed-off-by: Boteng Yao <boteng@google.com>

wdauchy force-pushed the eds_batch branch 9 times, most recently from 10ac01a to ca9dd67 Compare February 6, 2026 19:23

wdauchy force-pushed the eds_batch branch 2 times, most recently from bdd832d to d894e3d Compare February 13, 2026 19:16

wdauchy force-pushed the eds_batch branch from d894e3d to c1dabfa Compare February 14, 2026 08:37

wdauchy changed the title ~~upstream: defer PriorityUpdateCb during batch host updates~~ upstream: coalesce load balancer rebuilds during batch host updates Feb 14, 2026

wdauchy marked this pull request as ready for review February 14, 2026 14:25

wdauchy requested review from nezdolik, tonya11en and wbpcode as code owners February 14, 2026 14:25

botengyao assigned nezdolik Feb 18, 2026

Merge remote-tracking branch 'upstream/main' into eds_batch

c70f263

botengyao reviewed Feb 22, 2026

View reviewed changes

repokitteh-read-only Bot added the waiting label Feb 22, 2026

Merge remote-tracking branch 'upstream/main' into eds_batch

86a20b6

wdauchy force-pushed the eds_batch branch from bf58010 to 0085152 Compare February 22, 2026 13:59

add tests

7b1ada5

Signed-off-by: William Dauchy <william.dauchy@datadoghq.com>

wdauchy force-pushed the eds_batch branch from 0085152 to 7b1ada5 Compare February 22, 2026 15:16

repokitteh-read-only Bot assigned RyanTheOptimist Feb 22, 2026

wdauchy requested a review from botengyao February 22, 2026 16:33

botengyao reviewed Feb 22, 2026

View reviewed changes

wdauchy added 2 commits February 23, 2026 11:22

Merge remote-tracking branch 'upstream/main' into eds_batch

41fc876

coverage

36ba1ea

Signed-off-by: William Dauchy <william.dauchy@datadoghq.com>

nezdolik reviewed Feb 23, 2026

View reviewed changes

ordering

a4d9801

Signed-off-by: William Dauchy <william.dauchy@datadoghq.com>

nezdolik approved these changes Feb 23, 2026

View reviewed changes

wdauchy requested a review from botengyao February 23, 2026 12:16

botengyao approved these changes Feb 23, 2026

View reviewed changes

botengyao merged commit c0abf38 into envoyproxy:main Feb 23, 2026
28 checks passed

botengyao mentioned this pull request Mar 1, 2026

upstream: fix mid-batch thread-aware LB initialization out-of-bounds #43697

Merged

phlax added this to the 1.38.0 milestone Apr 16, 2026

Conversation

wdauchy commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

repokitteh-read-only Bot commented Feb 5, 2026

Uh oh!

botengyao commented Feb 18, 2026

Uh oh!

wdauchy commented Feb 19, 2026

Uh oh!

wdauchy commented Feb 20, 2026

Uh oh!

wdauchy commented Feb 20, 2026

Uh oh!

wdauchy commented Feb 20, 2026

Uh oh!

wdauchy commented Feb 20, 2026

Uh oh!

botengyao left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wdauchy commented Feb 22, 2026

Uh oh!

repokitteh-read-only Bot commented Feb 22, 2026

Uh oh!

wdauchy commented Feb 22, 2026

Uh oh!

botengyao left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nezdolik left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wdauchy Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

botengyao left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

wdauchy commented Feb 5, 2026 •

edited

Loading

wdauchy Feb 23, 2026 •

edited

Loading