[6/n] Migrate activation kernels, gptq, gguf, non cutlass w8a8 to libtorch stable ABI by mikaylagawarecki · Pull Request #38757 · vllm-project/vllm

mikaylagawarecki · 2026-04-01T21:55:45Z

Stacked on #38671, only the top 11 commits are relevant. Commits to review https://github.com/vllm-project/vllm/pull/38757/changes/2c13410412de95b648e9cd8562431dbe9481f9ee..deea6618c38afb4735b442c61e2697c273654292

Note: some declarations are not deleted from csrc/ops.h despite being moved to csrc/libtorch_stable/ops.h. This is because the CPU build also uses these declarations. These are

Activation kernels: silu_and_mul, gelu_and_mul, gelu_tanh_and_mul, gelu_new, gelu_fast, gelu_quick
W8A8 INT8 quantization: static_scaled_int8_quant, dynamic_scaled_int8_quant

Purpose

#26946

Test Plan

pytest tests/kernels/core/test_activation.py
pytest tests/kernels/quantization/test_ggml.py
pytest tests/kernels/quantization/test_fp8_quant.py
pytest tests/kernels/quantization/test_int8_quant.py

Test Result

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 ports several CUDA kernels, including activation, AWQ, AllSpark, MLA, and Hadacore, to the stable ABI extension (_C_stable_libtorch) and enables this extension for ROCm (HIP). Key changes include the introduction of a device property cache using raw CUDA/HIP APIs, updating headers to use header-only Torch utilities, and refactoring source files to use torch::stable::Tensor. Review feedback identified a compilation error in torch_utils.h where std::once_flag cannot be used with std::deque::resize due to its non-copyable nature, and logic errors in hadacore_transform related to in-place processing and padding.

gemini-code-assist · 2026-04-01T21:58:20Z

+#include <deque>
+#include <mutex>
+#include <string>
+#include <vector>
+
 // Stable ABI equivalent of TORCH_CHECK_NOT_IMPLEMENTED.
 #define STD_TORCH_CHECK_NOT_IMPLEMENTED(cond, ...) \
  STD_TORCH_CHECK(cond, "NotImplementedError: ", __VA_ARGS__)

+// Device properties cache for stable ABI compatibility.
+// Uses raw CUDA/HIP APIs instead of ATen functions.
+// Using inline ensures a single instance across all translation units.
+inline std::deque<std::once_flag> device_flags;
+inline std::vector<cudaDeviceProp> device_properties;
+inline std::once_flag vectors_init_flag;
+
+inline void do_init_device_vectors() {
+  int device_count;
+  cudaError_t err = cudaGetDeviceCount(&device_count);
+  if (err != cudaSuccess) {
+    STD_TORCH_CHECK(false, "cudaGetDeviceCount failed: " +
+                               std::string(cudaGetErrorString(err)));
+  }
+  device_flags.resize(device_count);
+  device_properties.resize(device_count);


The use of std::deque<std::once_flag> and calling resize() on it will cause a compilation error because std::once_flag is non-copyable and non-movable. std::deque::resize requires the element type to be MoveInsertable. A better approach is to use a std::unique_ptr<std::once_flag[]> to manage the flags dynamically after querying the device count. This requires including <memory>.

#include <memory> #include <mutex> #include <string> #include <vector> // Stable ABI equivalent of TORCH_CHECK_NOT_IMPLEMENTED. #define STD_TORCH_CHECK_NOT_IMPLEMENTED(cond, ...) \ STD_TORCH_CHECK(cond, "NotImplementedError: ", __VA_ARGS__) // Device properties cache for stable ABI compatibility. // Uses raw CUDA/HIP APIs instead of ATen functions. // Using inline ensures a single instance across all translation units. inline std::unique_ptr<std::once_flag[]> device_flags; inline std::vector<cudaDeviceProp> device_properties; inline std::once_flag vectors_init_flag; inline void do_init_device_vectors() { int device_count; cudaError_t err = cudaGetDeviceCount(&device_count); if (err != cudaSuccess) { STD_TORCH_CHECK(false, "cudaGetDeviceCount failed: " + std::string(cudaGetErrorString(err))); } device_flags = std::make_unique<std::once_flag[]>(device_count); device_properties.resize(device_count); }

see my comment on [5/n] #38671 (comment)

gemini-code-assist · 2026-04-01T21:58:20Z

      hadacore::run_fht<SCALAR_TYPE>(x.data_ptr(), x.data_ptr(), x.numel(), had_size, stream);
    });

    if (numel % 256 != 0) {
-        out = out.narrow(0, 0, numel / had_size);
+        out = torch::stable::narrow(out, 0, 0, numel / had_size);
    }

    if (inplace && out.data_ptr() != x.data_ptr()) {
-        x.copy_(out.view(res_shape));
+        torch::stable::copy_(x, torch::stable::view(out, res_shape));


There are critical logic errors in hadacore_transform regarding in-place operations and padding:

Incorrect Output Pointer: The kernel run_fht is called with x.data_ptr() as the output pointer (line 799). If inplace is false, the input tensor x is modified, and the returned tensor out remains uninitialized.

Incorrect Copy-back Logic: When inplace is true and padding occurs, x is reassigned to a new padded tensor. The result is written to this new tensor. However, line 807 copies from out (the original tensor) to x (the result tensor), which overwrites the computed result with the original input data. It should copy from x back to out.

To fix this, the kernel should write to out.data_ptr(). If inplace is true and padding occurred, the result should be copied from out (the padded result) back to the original input storage (after narrowing).

pre-existing?

mergify · 2026-04-02T04:41:07Z

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @mikaylagawarecki.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Pure move, no code changes. Preparatory step for stable ABI migration. Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Pure move, no code changes. Preparatory step for stable ABI migration. Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Restructure the stable ABI extension build so it compiles on both CUDA and HIP: - Widen outer guard to include HIP - Move CUDA-only sources (CUTLASS, FP4, AWQ, permute_cols) into a CUDA-conditional block - Gate USE_CUDA / CUTLASS_ENABLE_DIRECT_CUDA_DRIVER_CALL to CUDA; define USE_ROCM for HIP - Link PyTorch's bundled libamdhip64.so on ROCm to avoid a dual HIP runtime (from 985769a) - Enable _C_stable_libtorch in setup.py for HIP builds Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Move 9 basic activation ops (silu_and_mul, mul_and_silu, gelu_and_mul, gelu_tanh_and_mul, fatrelu_and_mul, swigluoai_and_mul, gelu_new, gelu_fast, gelu_quick) from the _C extension to _C_stable_libtorch. Convert ATen types/APIs to stable ABI equivalents: - torch::Tensor -> torch::stable::Tensor - ATen device guard/stream -> stable accelerator APIs - VLLM_DISPATCH_FLOATING_TYPES -> VLLM_STABLE_DISPATCH_FLOATING_TYPES - data_ptr -> mutable_data_ptr Quantized activation ops (silu_and_mul_quant, persistent_masked_m_silu_mul_quant) remain in _C. Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

mikaylagawarecki · 2026-04-02T17:21:02Z

@@ -1,17 +1,20 @@
 #include <cuda_fp16.h>
 #include <cuda_runtime.h>

-#include <torch/all.h>
-#include <c10/cuda/CUDAGuard.h>
+#include "../../../cuda_compat.h"


changes to use relative paths are due to hipification errors I ran into after moving files into the libtorch_stable subdirectory

mikaylagawarecki · 2026-04-02T17:47:19Z

-    torch::Tensor& out,          // [..., d]
-    torch::Tensor const& input,  // [..., d]
-    torch::Tensor const& scale,  // various shapes
-    std::optional<std::tuple<int64_t, int64_t>>


schema change here is bc stableivalue conversions don't support tuple, from the user perspective in python there is no change, also we assert the size below on 219

mikaylagawarecki · 2026-04-02T17:52:02Z

 void gelu_and_mul(torch::Tensor& out, torch::Tensor& input);

 void gelu_tanh_and_mul(torch::Tensor& out, torch::Tensor& input);

-void fatrelu_and_mul(torch::Tensor& out, torch::Tensor& input,


note: some declarations are not removed a the cpu build is using the declarations from ops.h too (tests will fail if we remove them)

Can you track these in the PR description?

Migrate static_scaled_fp8_quant, dynamic_scaled_fp8_quant, and dynamic_per_token_scaled_fp8_quant from _C to _C_stable_libtorch. Shared headers (common.cuh, utils.cuh) updated to work with both targets: utils.cuh uses torch::headeronly types; common.cuh uses Schema changed from (int,int)? to int[]? for group_shape to work with TORCH_BOX (std::tuple is not trivially copyable). Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Migrate gptq_gemm and gptq_shuffle from _C to _C_stable_libtorch. Key conversions: torch::Tensor -> torch::stable::Tensor, cuBLAS handle via get_current_cuda_blas_handle(), device().is_meta() check via DeviceType::Meta comparison, tensor creation via new_zeros/empty. Also removes #ifndef USE_ROCM guard on get_current_cuda_blas_handle() in torch_utils.h — hipify handles cublas_v2.h -> hipblas/hipblas.h and cublasHandle_t -> hipblasHandle_t automatically. Sub-headers (compat.cuh, matrix_view.cuh, qdq_*.cuh) are pure CUDA device code and need no changes. Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Co-authored-by: Claude Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

janeyx99 · 2026-04-02T19:14:47Z

 void gelu_and_mul(torch::Tensor& out, torch::Tensor& input);

 void gelu_tanh_and_mul(torch::Tensor& out, torch::Tensor& input);

-void fatrelu_and_mul(torch::Tensor& out, torch::Tensor& input,


Can you track these in the PR description?

janeyx99 · 2026-04-02T19:15:44Z


 #ifdef USE_ROCM
  #include <hip/hip_runtime.h>
+  #include <hip/hip_bf16.h>


why do we need these?

Concrete error without these is

AILED: [code=1] CMakeFiles/_C_stable_libtorch.dir/csrc/libtorch_stable/activation_kernels.hip.o ccache /opt/rocm/lib/llvm/bin/clang++ -DPy_LIMITED_API=3 -DTORCH_EXTENSION_NAME=_C_stable_libtorch -DTORCH_TARGET_VERSION=0x020A000000000000ULL -DUSE_C10D_GLOO -DUSE_C10D_NCCL -DUSE_DISTRIBUTED -DUSE_PROF_API=1 -DUSE_ROCM -DUSE_RPC -DUSE_TENSORPIPE -D_C_stable_libtorch_EXPORTS -D__HIP_PLATFORM_AMD__ -D__HIP_PLATFORM_AMD__=1 -D__HIP_ROCclr__=1 -I/data/users/mg1998/vllm/build/temp.linux-x86_64-cpython-312/csrc -isystem /home/mg1998/.conda/envs/pytorch/include/python3.12 -isystem /home/mg1998/.conda/envs/pytorch/lib/python3.12/site-packages/torch/include -isystem /home/mg1998/.conda/envs/pytorch/lib/python3.12/site-packages/torch/include/torch/csrc/api/include -isystem /usr/local/fbcode/platform010/lib/rocm-6.4.2/include/hiprand -isystem /usr/local/fbcode/platform010/lib/rocm-6.4.2/include/rocrand -Wno-unused-result -O2 -g -DNDEBUG -std=gnu++17 --offload-arch=gfx942 -fPIC -D__HIP_PLATFORM_AMD__=1 -DUSE_ROCM=1 -DHIPBLAS_V2 -fPIC -DCUDA_HAS_FP16=1 -D__HIP_NO_HALF_OPERATORS__=1 -D__HIP_NO_HALF_CONVERSIONS__=1 -DHIP_ENABLE_WARP_SYNC_BUILTINS=1 -DUSE_ROCM -DENABLE_FP8 -U__HIP_NO_HALF_CONVERSIONS__ -U__HIP_NO_HALF_OPERATORS__ -Werror=unused-variable -fno-gpu-rdc -DTORCH_HIP_VERSION=701 -Wno-shift-count-negative -Wno-shift-count-overflow -DCAFFE2_USE_MIOPEN -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_HIP -std=c++17 -DHIP_ENABLE_WARP_SYNC_BUILTINS -DHIPBLASLT_OUTER_VEC -DUSE_ROCM_CK_GEMM -MD -MT CMakeFiles/_C_stable_libtorch.dir/csrc/libtorch_stable/activation_kernels.hip.o -MF CMakeFiles/_C_stable_libtorch.dir/csrc/libtorch_stable/activation_kernels.hip.o.d -o CMakeFiles/_C_stable_libtorch.dir/csrc/libtorch_stable/activation_kernels.hip.o -x hip -c /data/users/mg1998/vllm/build/temp.linux-x86_64-cpython-312/csrc/libtorch_stable/activation_kernels.hip In file included from /data/users/mg1998/vllm/build/temp.linux-x86_64-cpython-312/csrc/libtorch_stable/activation_kernels.hip:8: /data/users/mg1998/vllm/build/temp.linux-x86_64-cpython-312/csrc/libtorch_stable/../hip_vec_utils.cuh:78:28: error: unknown type name '__hip_bfloat162'; did you mean 'hip_bfloat16'? 78 | struct PackedTypeConverter<__hip_bfloat162> { | ^~~~~~~~~~~~~~~ | hip_bfloat16 /opt/rocm/include/hip/amd_detail/amd_hip_bfloat16.h:57:8: note: 'hip_bfloat16' declared here 57 | struct hip_bfloat16 | ^ In file included from /data/users/mg1998/vllm/build/temp.linux-x86_64-cpython-312/csrc/libtorch_stable/activation_kernels.hip:8: /data/users/mg1998/vllm/build/temp.linux-x86_64-cpython-312/csrc/libtorch_stable/../hip_vec_utils.cuh:79:16: error: unknown type name '__hip_bfloat16'; did you mean 'hip_bfloat16'? 79 | using Type = __hip_bfloat16; | ^~~~~~~~~~~~~~ | hip_bfloat16 /opt/rocm/include/hip/amd_detail/amd_hip_bfloat16.h:57:8: note: 'hip_bfloat16' declared here 57 | struct hip_bfloat16 | ^

Ah concretely it seems like there is a bug here https://github.com/pytorch/pytorch/blob/main/torch/headeronly/util/BFloat16.h#L15-L17, the #include <cuda_bf16.h> gets hipified but the !defined(USE_ROCM) doeesn't

We defined USE_ROCM for _C_stable_libtorch to expose some of the shims that are gated :/

janeyx99 · 2026-04-02T19:17:25Z

  if(VLLM_GPU_LANG STREQUAL "CUDA")
    list(APPEND VLLM_STABLE_EXT_SRC
+      "csrc/cuda_utils_kernels.cu"
+      "csrc/cutlass_extensions/common.cpp"


how come this common.cpp needs to move to if CUDA?

edit: hmm wait just to confirm you were referring to csrc/cuda_utils_kernels.cu not common.cpp (which is correctly CUDA-only) right?

technically csrc/cuda_utils_kernels.cu should be shared cuda/rocm, but there's some issues with it being in sources for both extensions when building on rocm, so I want to punt that problem which will be solved when we fully migrate it out of _C

The error looks like

CMake Error: Running '/home/mg1998/.conda/envs/pytorch/bin/ninja' '-C' '/data/users/mg1998/vllm/build/temp.linux-x86_64-cpython-312' '-t' 'recompact' failed with: ninja: error: build.ninja:713: multiple rules generate csrc/hip_utils_kernels.hip

janeyx99 · 2026-04-02T19:19:54Z

-    # also _is_hip() once https://github.com/vllm-project/vllm/issues/35163 is
-    # fixed
-    if _is_cuda():
+    if _is_cuda() or _is_hip():


janeyx99 · 2026-04-02T19:20:48Z

+  # If PyTorch doesn't bundle libamdhip64 (built from source against system
+  # ROCm), there is only one copy in the process and no action is needed —
+  # the HIP compiler already links the system libamdhip64 automatically.
+  if(VLLM_GPU_LANG STREQUAL "HIP")


to improve my understanding, this code basically specifically picks out the amdhip64 that pytorch bundles in order to have deterministic correct results and not get corrupted?

yea concretely there seem to be two cases

pip installed pytorch on rocm (local) -- torch bundles libamdhip64, if we have raw hipFoo calls in vllm they will use the system rocm, but calls into hipFoo from libtorch itself will use torch's bundled libamdhip64 and there will be two device contexts -- we get gpucore dumps

rocm pytorch docker image (e.g. vllm CI) -- torch does not bundle libamdhip64, we are good.

mergify · 2026-04-08T21:23:25Z

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @mikaylagawarecki.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

mergify · 2026-05-18T14:49:22Z

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @mikaylagawarecki.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

janeyx99 · 2026-05-18T19:47:00Z

This PR will be landed in #42663 and can be closed

Harry-Chen · 2026-05-20T13:08:29Z

Superseded by newer PRs.

mergify Bot added ci/build nvidia rocm Related to AMD ROCm labels Apr 1, 2026

github-project-automation Bot added this to AMD and NVIDIA Apr 1, 2026

github-project-automation Bot moved this to Todo in AMD Apr 1, 2026

mikaylagawarecki force-pushed the new-stable-abi-phase6 branch from e65aea2 to 44a3cbc Compare April 1, 2026 21:58

gemini-code-assist Bot reviewed Apr 1, 2026

View reviewed changes

mikaylagawarecki changed the title ~~Migrate some shared CUDA/RoCM kernels to libtorch stable ABI~~ [6/n] Migrate some shared CUDA/RoCM kernels to libtorch stable ABI Apr 1, 2026

mikaylagawarecki force-pushed the new-stable-abi-phase6 branch 2 times, most recently from 969bfb0 to 60e21ce Compare April 1, 2026 22:28

mikaylagawarecki mentioned this pull request Apr 2, 2026

[7/n] Migrate pos_encoding and norm kernels to libtorch stable ABI #38783

Closed

5 tasks

mergify Bot added the needs-rebase label Apr 2, 2026

mikaylagawarecki added 16 commits April 2, 2026 08:58

Move CUTLASS MLA files from csrc to csrc/libtorch_stable

bfe9697

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

[a/n] Migrate CUTLASS MLA to torch stable ABI

e3606eb

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Move Hadamard files from csrc to csrc/libtorch_stable

ec7ca63

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

[b/n] Migrate Hadamard (hadacore) kernel to torch stable ABI

364e676

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Move AWQ files from csrc to csrc/libtorch_stable

f0b7eee

Pure move, no code changes. Preparatory step for stable ABI migration. Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

[c/n] Migrate AWQ kernels to torch stable ABI

3500eae

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Move DSV3 fused A GEMM from csrc to csrc/libtorch_stable

5e1b090

Pure move, no code changes. Preparatory step for stable ABI migration. Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

[d/n] Migrate DSV3 fused A GEMM to torch stable ABI

ec7793c

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Move AllSpark files from csrc to csrc/libtorch_stable

a9b1ed2

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

[e/n] Migrate AllSpark kernels to torch stable ABI

2c13410

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Move activation kernel file from csrc to csrc/libtorch_stable

f64dd26

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Move INT8 quant kernel file from csrc to csrc/libtorch_stable

66206be

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

[g/n] Migrate INT8 quant kernels to torch stable ABI

d0cf841

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Move FP8 quant kernel file from csrc to csrc/libtorch_stable

2fa10a1

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

mikaylagawarecki commented Apr 2, 2026

View reviewed changes

mikaylagawarecki force-pushed the new-stable-abi-phase6 branch 2 times, most recently from 675961a to e8f3b67 Compare April 2, 2026 18:36

mikaylagawarecki added 5 commits April 2, 2026 11:38

Move GPTQ kernel files from csrc to csrc/libtorch_stable

4e9bd85

Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

Move GGML/GGUF kernel files from csrc to csrc/libtorch_stable

aff8a2a

Co-authored-by: Claude Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

[j/n] Migrate GGML kernels to torch stable ABI

deea661

Co-authored-by: Claude Signed-off-by: Mikayla Gawarecki <mikaylagawarecki@gmail.com>

mikaylagawarecki force-pushed the new-stable-abi-phase6 branch from e8f3b67 to deea661 Compare April 2, 2026 18:39

janeyx99 approved these changes Apr 2, 2026

View reviewed changes

mikaylagawarecki marked this pull request as ready for review April 3, 2026 15:09

mikaylagawarecki requested review from LucasWilkinson, tjtanaa and tlrmchlsmth as code owners April 3, 2026 15:09

zou3519 approved these changes Apr 3, 2026

View reviewed changes

github-project-automation Bot moved this to Ready in NVIDIA Apr 3, 2026

mergify Bot added the needs-rebase label Apr 8, 2026

cleonard530 mentioned this pull request May 14, 2026

[6/n] Migrate activation kernels, gptq, gguf, non cutlass w8a8 to libtorch stable ABI (continued) #42663

Merged

5 tasks

mergify Bot removed the needs-rebase label May 18, 2026

mergify Bot added the needs-rebase label May 18, 2026

cleonard530 mentioned this pull request May 20, 2026

[7/n] Migrate pos_encoding and norm kernels to libtorch stable ABI (continued) #43209

Merged

5 tasks

Harry-Chen closed this May 20, 2026

github-project-automation Bot moved this from Ready to Done in NVIDIA May 20, 2026

github-project-automation Bot moved this from Todo to Done in AMD May 20, 2026

Uh oh!

Conversation

mikaylagawarecki commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Purpose

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 Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mergify Bot commented Apr 2, 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!

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!

mikaylagawarecki Apr 2, 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!

Choose a reason for hiding this comment

Uh oh!

mikaylagawarecki Apr 2, 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!

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!

mergify Bot commented Apr 8, 2026

Uh oh!

mergify Bot commented May 18, 2026

Uh oh!

janeyx99 commented May 18, 2026

Uh oh!

Harry-Chen commented May 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mikaylagawarecki commented Apr 1, 2026 •

edited

Loading

mikaylagawarecki Apr 2, 2026 •

edited

Loading

mikaylagawarecki Apr 2, 2026 •

edited

Loading