[MoE Refactor] Migrate Unquantized to Full Oracle Flow by yzong-rh · Pull Request #36286 · vllm-project/vllm

yzong-rh · 2026-03-06T22:16:35Z

Purpose

Migrate the unquantized MoE (BF16) code path from the legacy kernel initialization pattern to the modern modular pattern already used by FP8 and NvFP4.

The CPU backend is not migrated and remains on the old path due to interface differences (see below).

Background

There are unquantized

Monolithic backends (CPU, FlashInfer TRTLLM)
Non-monolithic backends (Triton, AITER, FlashInfer CUTLASS, XPU)

In the old path

Monolithic backends bypassed the oracle via UNSUPPORTED_BACKEND and were implemented in forward_monolithic_{cuda|cpu}.
Non-monolithic backends got a hardcoded NoDPEP prepare/finalize, which may be swapped for an appropriate prepare/finalize in prepare_communication_buffer_for_model (after weight loading and process_weights_after_loading).

This PR

Moves FlashInfer TRTLLM to the new MK flow, moving the logic from vllm/model_executor/layers/fused_moe/flashinfer_trtllm_moe.py to vllm/model_executor/layers/fused_moe/experts/trtllm_bf16_moe.py. Mirrors TrtLlmFp8Experts and [MoE Refactor] Create MK for TRTLLM Kernels #32564
Moves the non-monolithic backends to the new MK flow. Mirrors f8 and nvfp4 oracles in [MoE Refactor] Create MK for TRTLLM Kernels #32564
Leaves the CPU monolithic backend untouched.

Lifecycle: Old Path vs New Path

Non-monolithic (Triton, AITER, FlashInfer CUTLASS, XPU)

OLD                                          NEW
───                                          ───
UnquantizedFusedMoEMethod                    UnquantizedFusedMoEMethod
  ::process_weights_after_loading()            ::process_weights_after_loading()
  └─ UnquantizedFusedMoEMethod                 └─ UnquantizedFusedMoEMethod
       ::_setup_kernel()                            ::_setup_kernel()
       └─ make_unquantized_moe_kernel()             └─ make_unquantized_moe_kernel()
            hardcodes NoDPEP                             get appropriate PrepareAndFinalize
       └─ stored in self.kernel                     └─ stored in self.moe_kernel
       ∴ supports_internal_mk = False               ∴ supports_internal_mk = True

DeviceCommunicatorBase                       DeviceCommunicatorBase
  ::prepare_communication_buffer_for_model()   ::prepare_communication_buffer_for_model()
  └─ FusedMoE::maybe_init_modular_kernel()     └─ FusedMoE::maybe_init_modular_kernel()
       └─ RUNS: may wrap quant method               └─ NO-OP (early return supports_internal_mk = True)
          with FusedMoEModularMethod

FusedMoE::forward()                          FusedMoE::forward()
  └─ MoERunner::forward()                     └─ MoERunner::forward()
       ├─ router selects topK                      ├─ router selects topK
       ├─ if dp>1: runner dispatches/combines      ├─ (kernel handles dispatch internally)
       └─ UnquantizedFusedMoEMethod::apply()       └─ UnquantizedFusedMoEMethod::apply()
            └─ FusedMoEKernel::apply()                  └─ FusedMoEKernel::apply()

Monolithic — GPU (FlashInfer TRTLLM)

OLD                                          NEW
───                                          ───
UnquantizedFusedMoEMethod                    UnquantizedFusedMoEMethod
  ::process_weights_after_loading()            ::process_weights_after_loading()
  └─ UnquantizedFusedMoEMethod                 └─ UnquantizedFusedMoEMethod
       ::_setup_kernel()                            ::_setup_kernel()
       └─ SKIPPED (in UNSUPPORTED_BACKEND)          └─ make_unquantized_moe_kernel()
       └─ _is_monolithic set manually                    builds FusedMoEKernel
       └─ self.moe_kernel = None                         with TrtLlmBf16Experts
                                                    └─ stored in self.moe_kernel
                                                    ∴ supports_internal_mk = True

DeviceCommunicatorBase                       DeviceCommunicatorBase
  ::prepare_communication_buffer_for_model()   ::prepare_communication_buffer_for_model()
  └─ FusedMoE::maybe_init_modular_kernel()     └─ FusedMoE::maybe_init_modular_kernel()
       └─ NO-OP (is_monolithic = True)              └─ NO-OP (is_monolithic = True)

FusedMoE::forward()                          FusedMoE::forward()
  └─ MoERunner::forward()                     └─ MoERunner::forward()
       └─ UnquantizedFusedMoEMethod                └─ UnquantizedFusedMoEMethod
            ::apply_monolithic()                        ::apply_monolithic()
            └─ forward_monolithic_cuda()                └─ FusedMoEKernel
               (hand-written, bypasses oracle)               ::apply_monolithic()

Monolithic — CPU (not migrated, unchanged)

UnquantizedFusedMoEMethod
  ::process_weights_after_loading()
  └─ UnquantizedFusedMoEMethod::_setup_kernel()
       └─ SKIPPED (backend == CPU)
       └─ self.moe_kernel = None, is_monolithic = True (hardcoded)
       └─ self.cpu_fused_moe set up directly

DeviceCommunicatorBase
  ::prepare_communication_buffer_for_model()
  └─ FusedMoE::maybe_init_modular_kernel()
       └─ NO-OP (is_monolithic = True)

FusedMoE::forward()
  └─ MoERunner::forward()
       └─ UnquantizedFusedMoEMethod::apply_monolithic()
            └─ self.cpu_fused_moe(...)  (bypasses oracle)

Changes

New file: experts/trtllm_bf16_moe.py — TrtLlmBf16Experts, a FusedMoEExpertsMonolithic subclass wrapping the flashinfer.fused_moe.trtllm_bf16_moe call.

oracle/unquantized.py:

select_unquantized_moe_backend now returns (backend, experts_cls) instead of just backend, mirroring FP8. CPU returns (CPU, None).
Removed UNSUPPORTED_BACKEND. Added BATCHED_TRITON enum variant and backend_to_kernel_cls mapping.
Backend selection uses FP8's priority-list fallback pattern: iterate candidates, call is_supported_config, log and skip unsupported ones.
make_unquantized_moe_kernel now calls maybe_make_prepare_finalize(allow_new_interface=True) instead of hardcoding NoDPEP, and always returns a FusedMoEKernel.
FlashInfer TRTLLM weight preprocessing (w13 half-swap + block layout) moved into convert_to_unquantized_kernel_format.

unquantized_fused_moe_method.py:

__init__ stores experts_cls from the backend selector. Removed self.kernel, _is_monolithic, and _select_monolithic.
_setup_kernel stores the kernel in self.moe_kernel (not self.kernel), making supports_internal_mk=True and causing maybe_init_modular_kernel to no-op.
is_monolithic returns True for CPU, delegates to super() otherwise.
forward_native and forward_cuda use self.moe_kernel.apply().
apply_monolithic dispatches CPU to self.cpu_fused_moe, all others to self.moe_kernel.apply_monolithic().
Removed forward_monolithic_cuda, select_gemm_impl, and the FlashInfer TRTLLM branch from process_weights_after_loading.

Other cleanups:

Removed dead rocm_aiter_moe_enabled condition.
TPU/OOT backends replaced with NONE (mirrors [Bugfix][TPU] Return a Default fp8 MoE Backend #32908).
Added guard against shared_experts passed to FusedMoEExpertsMonolithic.
Strengthened FlashInfer backend platform checks.

The CPU backend (CPUFusedMOE/SGLFusedMOE) stays on the old monolithic path because it has three interface differences that make a clean migration non-trivial:

It performs its own routing with parameters not in FusedMoEConfig (renormalize, scoring_func, custom_routing_function).
It selects between three sub-strategies (SGL, Grouped GEMM, Torch fallback) at weight-loading time based on hardware ISA detection.
The Torch fallback stores per-expert closures on the layer object, unlike the standard apply(w1, w2, ...) interface.

Test Plan

Integration tests:

moe-refactor/Mixtral-8x7B-BF16-triton.yaml
moe-refactor/Mixtral-8x7B-BF16-fi-cutlass.yaml
moe-refactor/Qwen3-30B-A3B-BF16-triton.yaml
moe-refactor/Qwen3-30B-A3B-BF16-fi-cutlass.yaml

Updated unit tests:

pytest -v -s tests/kernels/moe/test_unquantized_backend_selection.py
pytest -v -s tests/kernels/moe/test_moe.py::test_unquantized_bf16_flashinfer_trtllm_backend

Other unit tests:

pytest -v -s tests/kernels/moe/test_flashinfer.py::test_convert_moe_weights_to_flashinfer_trtllm_block_layout
pytest -v -s tests/kernels/moe/test_moe.py::test_fused_moe
pytest -v -s tests/kernels/moe/test_moe.py::test_naive_block_assignment_moe
pytest -v -s tests/distributed/test_expert_parallel.py -k Mixtral
pytest -v -s tests/distributed/test_eplb_fused_moe_layer.py

Test Result

Config	Expected Accuracy	Measured Accuracy
Mixtral-8x7B-BF16-triton	0.5800	0.5572
Mixtral-8x7B-BF16-fi-cutlass	0.5800	0.5686
Qwen3-30B-A3B-BF16-triton.yaml	0.8800	0.8931
Qwen3-30B-A3B-BF16-fi-cutlass.yaml	0.8800	0.8886

All unit tests pass on B200 machine

cc @robertgshaw2-redhat @bnellnm

Essential Elements of an Effective PR Description Checklist

The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
The test plan, such as providing test command.
The test results, such as pasting the results comparison before and after, or e2e results
(Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
(Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

gemini-code-assist

Code Review

This pull request is a significant and well-executed refactoring of the Mixture of Experts (MoE) infrastructure, migrating the unquantized MoE method and its selection oracle to the new modular kernel (MK) flow. This greatly improves the modularity, maintainability, and extensibility of the MoE implementation. Key changes include the introduction of TrtLlmBf16Experts as a new modular kernel, a completely rewritten and more robust backend selection oracle for unquantized MoE, and strengthened platform support checks for various FlashInfer backends. The code is well-structured and successfully moves towards a more unified MoE framework. I've identified one area for improvement to ensure the correctness of the new backend's support check.

gemini-code-assist · 2026-03-06T22:18:58Z

vllm/utils/flashinfer.py

        ("flashinfer.fused_moe", "trtllm_fp8_per_tensor_scale_moe"),
        ("flashinfer.fused_moe", "trtllm_fp4_block_scale_moe"),
        ("flashinfer.fused_moe", "trtllm_mxint4_block_scale_moe"),
+        # TODO: Add check for `trtllm_bf16_moe`?


The TODO comment highlights a missing check for trtllm_bf16_moe. The has_flashinfer_trtllm_fused_moe function is used by TrtLlmBf16Experts to determine if the kernel is supported. Without this check, the system might incorrectly report support for the bf16 TRT-LLM kernel, potentially leading to a runtime error if the trtllm_bf16_moe function is missing from the flashinfer library. Please add the check to ensure correctness.

Suggested change

# TODO: Add check for `trtllm_bf16_moe`?

("flashinfer.fused_moe", "trtllm_bf16_moe"),

TODO is intentional. I'd like to get some eyes on this before adding it or removing the TODO.

github-actions · 2026-03-06T22:43:11Z

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors.

You ask your reviewers to trigger select CI tests on top of fastcheck CI.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

🚀

yzong-rh · 2026-03-07T01:52:01Z

vllm/model_executor/layers/fused_moe/oracle/unquantized.py

+            w2_weight,
+        )

    return w13_weight, w2_weight


Not sure if we need to ensure these weights are contiguous()

bnellnm · 2026-03-10T15:35:04Z

vllm/model_executor/layers/fused_moe/oracle/fp8.py

+            if (
+                moe_config.moe_parallel_config.use_all2all_kernels and not is_monolithic
+            )


Is this check because the monolithic path doesn't implement shared_experts? If so, do we have an assert for that?

Yeah, monolithic path does not support shared_experts. We do an assert within FusedMoEKernel when we use the monolithic implementation.

Technically, we assert that inplace is False as well, but from Rob's comment here, it seems there are plans to support inplace so I didn't add a check there.

bnellnm

Looks good to me. Just had one minor question.

…land Signed-off-by: Bill Nell <bnell@redhat.com>

vllm/lora/layers/fused_moe.py

robertgshaw2-redhat · 2026-03-10T22:34:57Z

vllm/model_executor/layers/fused_moe/oracle/fp8.py

        shared_experts=(
            shared_experts
-            if moe_config.moe_parallel_config.use_all2all_kernels
+            if (


I fixed this issue here: #36061, so we can remove this once #36061 lands

actually, you can remove this now, its not relevant to this PR

robertgshaw2-redhat · 2026-03-10T22:35:06Z

vllm/model_executor/layers/fused_moe/oracle/nvfp4.py

        shared_experts=(
            shared_experts
-            if moe_config.moe_parallel_config.use_all2all_kernels
+            if (


ditto, nice catch on this

but we can remove it since its irrelevant to this PR

robertgshaw2-redhat · 2026-03-10T22:36:06Z

vllm/model_executor/layers/fused_moe/unquantized_fused_moe_method.py

-        shared_experts_input: torch.Tensor | None,
-    ) -> torch.Tensor | tuple[torch.Tensor, torch.Tensor]:
-        return self.forward_cuda(layer, x, topk_weights, topk_ids, shared_experts_input)
+        assert self.unquantized_backend != UnquantizedMoeBackend.NONE


what causes this to return NONE for backend?

NONE backend is returned for TPU and OOT.

vllm/model_executor/layers/fused_moe/unquantized_fused_moe_method.py

robertgshaw2-redhat · 2026-03-10T22:42:14Z

vllm/model_executor/layers/fused_moe/unquantized_fused_moe_method.py


 # --8<-- [start:unquantized_fused_moe]
 @CustomOp.register("unquantized_fused_moe")
 class UnquantizedFusedMoEMethod(FusedMoEMethodBase, CustomOp):


note to self, we should make this not be a CustomOp in the future

robertgshaw2-redhat · 2026-03-10T22:48:46Z

vllm/model_executor/layers/fused_moe/flashinfer_cutedsl_moe.py

    def _supports_current_device() -> bool:
        p = current_platform
-        return p.is_cuda() and p.is_device_capability_family(100)
+        return (


this is a good fix, but irrelevant to this PR. Please remove it and we can add it in a separate PR

robertgshaw2-redhat · 2026-03-10T22:49:16Z

vllm/model_executor/layers/fused_moe/experts/trtllm_nvfp4_moe.py

        """Supports only Blackwell-family GPUs."""
        p = current_platform
-        return p.is_cuda() and p.is_device_capability_family(100)
+        return (


good fix, but irrelevant to this PR. Please remove it and we can add it in another Pr

robertgshaw2-redhat · 2026-03-10T22:49:31Z

vllm/model_executor/layers/fused_moe/experts/trtllm_fp8_moe.py

        p = current_platform
-        # Add check flashinfer trtllm is available
-        return p.is_cuda() and p.is_device_capability_family(100)
+        return (


good fix, but irrelevant for this PR, please remove it and open up another PR

robertgshaw2-redhat · 2026-03-10T22:50:51Z

vllm/utils/flashinfer.py

        ("flashinfer.fused_moe", "trtllm_fp8_per_tensor_scale_moe"),
        ("flashinfer.fused_moe", "trtllm_fp4_block_scale_moe"),
        ("flashinfer.fused_moe", "trtllm_mxint4_block_scale_moe"),
+        # TODO: Add check for `trtllm_bf16_moe`?


Sg, will do it in the other PR with the others

robertgshaw2-redhat · 2026-03-10T22:59:21Z

vllm/model_executor/layers/fused_moe/oracle/unquantized.py



 class UnquantizedMoeBackend(Enum):
+    NONE = "NONE"


can you update this to match the style of the other oracles?

robertgshaw2-redhat · 2026-03-10T23:01:44Z

vllm/model_executor/layers/fused_moe/oracle/unquantized.py

-    if current_platform.is_out_of_tree():
-        backend = UnquantizedMoeBackend.OOT
+    for backend in AVAILABLE_BACKENDS:
+        backend = _maybe_swap_to_batched_variant(backend)


I would prefer if this function did not exist. we now have 2 spots where we set AVAILABLE_BACKENDS. I would suggest just having BATCHED_TRITON in the lists above

Signed-off-by: Yifan Zong <yzong@redhat.com>

1. override and throw in `select_gemm_impl` 2. remove `NONE` backend and throw early on TPU/OOT platforms 3. remove _maybe_swap_to_batched_variant so that AVAILABLE_BACKENDS is set in one location 4. Use use_deepep_ll_kernels instead of use_all2all_kernels Signed-off-by: Yifan Zong <yzong@redhat.com>

yzong-rh

Botched a rebase and accidentally notified everyone. Sorry!

Sorry about the noise. No further action is required from you.

~~Further commits are added to #36732 .~~

vllm/model_executor/layers/fused_moe/oracle/unquantized.py

vllm/model_executor/layers/fused_moe/unquantized_fused_moe_method.py

Signed-off-by: Yifan Zong <yzong@redhat.com>

vllm/model_executor/layers/fused_moe/oracle/unquantized.py

bnellnm

LGTM as long as @robertgshaw2-redhat 's comments are addressed.

Signed-off-by: Robert Shaw <robshaw@redhat.com>

yzong-rh · 2026-03-21T03:37:15Z

WIP triage of CI failures: https://gist.github.com/yzong-rh/134ce7b202a35800d90a5f41c8318969
Not sure why unquantized CUTLASS isn't working.

robertgshaw2-redhat · 2026-03-21T14:17:11Z

I broke everything!

Signed-off-by: Robert Shaw <robshaw@redhat.com>

…zed-refactor

Signed-off-by: Robert Shaw <robshaw@redhat.com>

yzong-rh changed the title ~~[MoE Refactor] Migrate UnquantizedFusedMoEMethod and oracle to MK flow#1~~ [MoE Refactor] Migrate UnquantizedFusedMoEMethod and oracle to MK flow Mar 6, 2026

mergify bot added the nvidia label Mar 6, 2026

github-project-automation bot added this to NVIDIA Mar 6, 2026

gemini-code-assist bot reviewed Mar 6, 2026

View reviewed changes

yzong-rh marked this pull request as ready for review March 7, 2026 01:29

yzong-rh requested review from WoosukKwon, jeejeelee, mgoin, pavanimajety, tlrmchlsmth and yewentao256 as code owners March 7, 2026 01:29

yzong-rh commented Mar 7, 2026

View reviewed changes

bnellnm reviewed Mar 10, 2026

View reviewed changes

bnellnm approved these changes Mar 10, 2026

View reviewed changes

bnellnm requested a review from robertgshaw2-redhat March 10, 2026 18:26

bnellnm added a commit to neuralmagic/vllm that referenced this pull request Mar 10, 2026

back out unquantized changes for now. wait for vllm-project#36286 to …

a4d35b7

…land Signed-off-by: Bill Nell <bnell@redhat.com>

robertgshaw2-redhat reviewed Mar 10, 2026

View reviewed changes

vllm/lora/layers/fused_moe.py Show resolved Hide resolved

robertgshaw2-redhat reviewed Mar 10, 2026

View reviewed changes

vllm/model_executor/layers/fused_moe/unquantized_fused_moe_method.py Show resolved Hide resolved

robertgshaw2-redhat reviewed Mar 10, 2026

View reviewed changes

yzong-rh added 2 commits March 10, 2026 21:01

[MoE] remove irrelevant bug fixes from fp8 and nvfp4 oracles

29941df

Signed-off-by: Yifan Zong <yzong@redhat.com>

yzong-rh force-pushed the yzong-rh/moe-unquantized-refactor branch from 457b939 to 1e36445 Compare March 11, 2026 01:02

mergify bot mentioned this pull request Mar 11, 2026

[MoE Refactor] Migrate UnquantizedFusedMoEMethod and oracle to MK flow #36732

Closed

5 tasks

yzong-rh commented Mar 11, 2026

View reviewed changes

vllm/model_executor/layers/fused_moe/oracle/unquantized.py Show resolved Hide resolved

vllm/model_executor/layers/fused_moe/unquantized_fused_moe_method.py Show resolved Hide resolved

bigPYJ1151 mentioned this pull request Mar 11, 2026

[CPU Backend] Refactor CPU FusedMoE to MK flow #36739

Open

1 task

bnellnm removed request for noooop, russellb, sighingnow, tdoublep and zou3519 March 11, 2026 16:41

[Bug] Fix typos and _supports_current_devicheck

1d1b5fb

Signed-off-by: Yifan Zong <yzong@redhat.com>

bnellnm reviewed Mar 17, 2026

View reviewed changes

vllm/model_executor/layers/fused_moe/oracle/unquantized.py Show resolved Hide resolved

bnellnm approved these changes Mar 17, 2026

View reviewed changes

robertgshaw2-redhat and others added 4 commits March 20, 2026 17:29

Merge branch 'main' into yzong-rh/moe-unquantized-refactor

dac583e

fix naive a2a naming

71da7e8

Signed-off-by: Robert Shaw <robshaw@redhat.com>

re-enable the tpu sutff

3c38c88

Signed-off-by: Robert Shaw <robshaw@redhat.com>

updated

921b431

Signed-off-by: Robert Shaw <robshaw@redhat.com>

Robert Shaw added 9 commits March 21, 2026 10:18

fix backend selection

915372b

Signed-off-by: Robert Shaw <robshaw@redhat.com>

fix backend selection

befe36b

Signed-off-by: Robert Shaw <robshaw@redhat.com>

fix ROCM AITER in test mixtral

493630c

Signed-off-by: Robert Shaw <robshaw@redhat.com>

remove qwen3

f1e3c5e

Signed-off-by: Robert Shaw <robshaw@redhat.com>

add batch invariance selection

611c574

Signed-off-by: Robert Shaw <robshaw@redhat.com>

updated

c40ddf8

Signed-off-by: Robert Shaw <robshaw@redhat.com>

Merge remote-tracking branch 'origin/main' into yzong-rh/moe-unquanti…

a4b121f

…zed-refactor

fix failing tests

cf5e0d2

Signed-off-by: Robert Shaw <robshaw@redhat.com>

fix oracle selection for qwen3.5

7df028c

Signed-off-by: Robert Shaw <robshaw@redhat.com>

robertgshaw2-redhat mentioned this pull request Mar 21, 2026

[MoE] Unify MoE oracles with class structure #37776

Open

5 tasks

	# TODO: Add check for `trtllm_bf16_moe`?
	("flashinfer.fused_moe", "trtllm_bf16_moe"),

Uh oh!

Conversation

yzong-rh commented Mar 6, 2026 • edited by github-actions bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Purpose

Background

In the old path

This PR

Lifecycle: Old Path vs New Path

Non-monolithic (Triton, AITER, FlashInfer CUTLASS, XPU)

Monolithic — GPU (FlashInfer TRTLLM)

Monolithic — CPU (not migrated, unchanged)

Changes

Test Plan

Test Result

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

yzong-rh Mar 6, 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!

github-actions bot commented Mar 6, 2026

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!

bnellnm left a comment • 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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

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!

yzong-rh left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Botched a rebase and accidentally notified everyone. Sorry!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bnellnm left a comment

Choose a reason for hiding this comment

Uh oh!

yzong-rh commented Mar 6, 2026 •

edited by github-actions bot

Loading

yzong-rh Mar 6, 2026 •

edited

Loading

bnellnm left a comment •

edited

Loading

yzong-rh left a comment •

edited

Loading