[Wasm RyuJit] asserts crossgenning wasm debug SPC

Debug SPC Asserts

(1) Assertion failed 'isInitBlk == src->gtSkipReloadOrCopy()->IsInitVal()'

Single method repro args:--singlemethodtypename "System.Array" --singlemethodname "Ctor" --singlemethodindex 2
C:\repos\runtime2\src\coreclr\jit\gentree.h:9528
Assertion failed 'isInitBlk == src->gtSkipReloadOrCopy()->IsInitVal()' in 'System.Array:Ctor(ptr,uint,ptr):System.Array' during 'Linear scan register alloc' (IL size 25; hash 0xfb8a8728; MinOpts)

In the above the IR node is

N006 (???,???) [000007] --CXG+-----                    t7 = *  CALL r2r_ind int    System.Runtime.CompilerServices.ObjectHandleOnStack:Create[System.__Canon](byref):System.Runtime.CompilerServices.ObjectHandleOnStack
                                                            /--*  t7     int
N007 (???,???) [000016] DACXG+-----                         *  STORE_LCL_VAR struct<System.Runtime.CompilerServices.ObjectHandleOnStack, 4> V10 tmp3

and we seem to have an assumption that if the source of a block store is TYP_INT then the source must be an INIT_VAL.

(2) Assertion failed 'emitTypeSizes[TypeGet(type)] > 0'

Single method repro args:--singlemethodtypename "System.GC" --singlemethodname "GetGCMemoryInfo" --singlemethodindex 2
C:\repos\runtime2\src\coreclr\jit\emit.h:3925
Assertion failed 'emitTypeSizes[TypeGet(type)] > 0' in 'System.GC:GetGCMemoryInfo(int):System.GCMemoryInfo' during 'Generate code' (IL size 75; hash 0xec24fb45; MinOpts)

FYI @dotnet/jit-contrib

@kg

Debug SPC Wasm Validation Errors

If you can get past these asserts and use #125752 to get past the WASM_NYI, and are using @kg's test harness, you will then hit some validation errors as the Wasm engine tries to ingest our codegen.

(1) not enough arguments on the stack for memory.copy (need 3, got 2)

[CompileError: WebAssembly.compile(): Compiling function #42 failed: not enough arguments on the stack for memory.copy (need 3, got 2) @+2439733]

which seems to be from this single instance:

--singlemethodname=GetValue
--singlemethodtypename=System.Array
--singlemethodindex=3

Here's a bit of the Wasm stream...

#42 S_P_CoreLib_System_Array__GetValue ( i32, i32, i32, i32 ) -> i32 (327 byte(s))
@2439509  2000        get_local 0 ; i32 arg0
@2439511  41C000      i32_const 0x00000040 ; 64
@2439514  6B          i32_s
...
@2439726  2000        get_local 0 ; i32 arg0
@2439728  4104        i32_const 4
@2439730  6A          i32_add 
@2439731  4108        i32_const 8
@2439733  FC0A0000    memory_copy

JIT IR here is

               [000101] D----------                  t101 =    LCL_ADDR  byref  V16 tmp8         [+0]
N001 (???,???) [000042] -c---+-----                   t42 =    LCL_VAR   struct<System.ReadOnlySpan`1, 8>(DA) V13 tmp5
                                                            /--*  t101   byref
                                                            +--*  t42    struct
N002 (???,???) [000070] sA---+-----                         *  STORE_BLK struct<System.ReadOnlySpan`1, 8> (copy) (memory.copy)

Looks like we are not properly handling a contained source in codegen?

(2) i64.shl[1] expected type i64, found i32.const of type i32

[CompileError: WebAssembly.compile(): Compiling function #134 failed: i64.shl[1] expected type i64, found i32.const of type i32 @+1214826]

This is from

--singlemethodtypename:System.Decimal 
--singlemethodname:.ctor 
--singlemethodindex:8

wasm is

IN00d4: 00021E      i32.load 0 0      ;; V12
IN00d5: 000221      i64.extend_s_i32
IN00d6: 000222      i32.const 32
IN00d7: 000224      i64.shl

and codegen is

Generating: N004 (???,???) [000040] -----+-----                   t40 =    LCL_VAR   int    V12 tmp7
IN00d3:             local.get 0
IN00d4:             i32.load 0 0      ;; V12
                                                                        /--*  t40    int
Generating: N005 (???,???) [000041] -----+-----                   t41 = *  CAST      long <- int
IN00d5:             i64.extend_s_i32
Generating: N006 (???,???) [000042] -----+-----                   t42 =    CNS_INT   int    32
IN00d6:             i32.const 32
                                                                        /--*  t41    long
                                                                        +--*  t42    int
Generating: N007 (???,???) [000043] -----+-----                   t43 = *  LSH       long
IN00d7:             i64.shl

Think this is just a semantic mismatch, in our trees the shift amount is probably always TYP_INT.

And indeed:

runtime/src/coreclr/jit/codegenwasm.cpp

Lines 1471 to 1473 in 0d2f781

    
           // TODO-WASM: Zero-extend the 2nd operand for shifts and rotates as needed when the 1st and 2nd operand are 
        
           // different types. The shift operand width in IR is always TYP_INT; the WASM operations have the same widths 
        
           // for both the shift and shiftee. So the shift may need to be extended (zero-extended) for TYP_LONG.

Fix will be something like:

@@ -1477,6 +1477,14 @@ void CodeGen::genCodeForShift(GenTree* tree)
     // different types. The shift operand width in IR is always TYP_INT; the WASM operations have the same widths
     // for both the shift and shiftee. So the shift may need to be extended (zero-extended) for TYP_LONG.

+    if (treeNode->TypeIs(TYP_LONG))
+    {
+        assert(treeNode->gtGetOp2()->TypeIs(TYP_INT));
+        // Zero-extend the shift amount to 64 bits for long shifts/rotates.
+        // Wasteful if the amount was a constant, perhaps we should contain it if so.
+        GetEmitter()->emitIns(INS_i64_extend_u_i32);
+    }
+

(3) call_indirect[2] expected type i64, found i32.load of type i32

[CompileError: WebAssembly.compile(): Compiling function #286 failed: call_indirect[2] expected type i64, found i32.load of type i32 @+1247187]

This is

--singlemethodtypename:System.Environment+ProcessCpuUsage
--singlemethodname:get_TotalTime
--singlemethodindex:1

also seen in

--singlemethodindex:3
--singlemethodtypename:System.GC
--singlemethodname:WaitForFullGCApproach

think it is this bit of wasm

@0305  2000           get_local 0 ; i32 arg0
@0307  2000           get_local 0 ; i32 arg0
@0309  4100           i32_const 0
@0311  2000           get_local 0 ; i32 arg0
@0313  280010         i32_load +16
@0316  2000           get_local 0 ; i32 arg0
@0318  280008         i32_load +8
@0321  4100           i32_const 0
@0323  280000         i32_load +0
@0326  11818080800000 call_indirect 1 tables[0] ; l(iill)

and this bit of IR

Generating: N001 (???,???) [000017] -----+-----                   t17 =    PHYSREG   int    $0
IN001e:             local.get 0
Generating: N002 (???,???) [000016] H----+-----                   t16 =    CNS_INT(h) int    0x420088 ftn
IN001f:             i32.const 0
Generating: N003 (???,???) [000019] -----+-----                   t19 =    LCL_FLD   int    V03 loc1         [+0]
IN0020:             local.get 0
IN0021:             i32.load 0 16      ;; V03
Generating: N004 (???,???) [000021] -----+-----                   t21 =    LCL_FLD   int    V04 tmp1         [+0]
IN0022:             local.get 0
IN0023:             i32.load 0 8      ;; V04
Generating: N001 (???,???) [000030] H----------                   t30 =    CNS_INT(h) int    0x420088 ftn
IN0024:             i32.const 0
                                                                        /--*  t30    int
Generating: N002 (???,???) [000031] n---G------                   t31 = *  IND       int
IN0025:             i32.load 0 0
                                                                        /--*  t17    int    wasm sp $0
                                                                        +--*  t16    int    r2r cell $1
                                                                        +--*  t19    int    arg2 $2
                                                                        +--*  t21    int    arg3 $3
                                                                        +--*  t31    int    control expr
Generating: N005 (???,???) [000008] --CXG+-----                    t8 = *  CALL r2r_ind long   System.TimeSpan:op_Addition(System.TimeSpan,System.TimeSpan):System.TimeSpan

TimeSpan is 8 bytes, so the call sig looks to be correct.

Not sure yet why we are passing those args as ints...

(4) i64.and[0] expected type i64, found i64.eq of type i32

--singlemethodtypename:System.Math
--singlemethodname:DivRem
--singlemethodindex:2

wasm is

@0292  2007           get_local 7 ; i64 local2
@0294  427F           i64_const 0xFFFFFFFFFFFFFFFF ; -1
@0296  51             i64_eq
@0297  2006           get_local 6 ; i64 local1
@0299  4280808080808080 ...
80807F                i64_const 0xFFFFFFFFFFFFFFC0 ; -64
@0310  51             i64_eq
@0311  83             i64_and

Wasm relops always produce i32 results. Should be a simple fix.

(5) i32.clz[0] expected type i32, found i64.load of type i64

--singlemethodtypename:System.Math
--singlemethodname:ILogB
--singlemethodindex:1

wasm is

@0555  2000           ......get_local 0 ; i32 arg0
@0557  290004         ......i64_load +4
@0560  67             ......i32_clz

Seems like it should also be as simple fix... need to dispatch based on source type, and then truncate the result to 32 bits.

I'll take a look at the two block store issues.

I have fixes for validation cases (2-5) above. Am going to keep pushing on validation for a bit before I PR these.

With those the first 1530 or so of methods validate, but error case (3) starts to dominate and is painful to work around. Let me see if I can fix it.

Using the first repro, things look good heading into morph:

fgMorphTree BB01, STMT00002 (before)
               [000009] DAC-G------                         *  STORE_LCL_VAR struct<System.TimeSpan, 8> V05 tmp2         
               [000008] --C-G------                         \--*  CALL r2r_ind struct System.TimeSpan:op_Addition(System.TimeSpan,System.TimeSpan):System.TimeSpan
               [000003] ----------- arg0                       +--*  LCL_VAR   struct<System.TimeSpan, 8> V03 loc1         
               [000007] ----------- arg1                       \--*  LCL_VAR   struct<System.TimeSpan, 8> V04 tmp1         
Adding final args and determining ABI info for [000008]:
Argument 0 ABI info: [00..04) reg $0
Argument 1 ABI info: [00..08) reg $1
Argument 2 ABI info: [00..08) reg $2
Argument 3 ABI info: [00..04) reg $3
Args for call [000008] CALL after AddFinalArgsAndDetermineABIInfo:
CallArg[[000017].LCL_VAR int (By value), 1 segments: <[00..04) reg $0>, wellKnown[WasmShadowStackPointer]]
CallArg[[000003].LCL_VAR struct (By value), 1 segments: <[00..08) reg $1>]
CallArg[[000007].LCL_VAR struct (By value), 1 segments: <[00..08) reg $2>]
CallArg[[000016].CNS_INT int (By value), 1 segments: <[00..04) reg $3>, wellKnown[R2RIndirectionCell]]

TimeSpan is a struct that wraps a long so indeed is passed and returned by value for Wasm.

But then things go off the rails:

Morphing args for 8.CALL:
Struct argument V03: CallArg[[000003].LCL_VAR struct (By value), 1 segments: <[00..08) reg $1>]
fgTryMorphStructArg created tree:
               [000019] -----+-----                         *  LCL_FLD   int    V03 loc1         [+0]
Struct argument V04: CallArg[[000007].LCL_VAR struct (By value), 1 segments: <[00..08) reg $2>]
fgTryMorphStructArg created tree:
               [000021] -----+-----                         *  LCL_FLD   int    V04 tmp1         [+0]

Fix seems fairly simple, just use the seg type for passing "in register" structs for Wasm.

More Debug SPC Wasm Validation Errors

Now hitting

(6) invalid numeric opcode: 0xfc41

--singlemethodtypename:System.Half
--singlemethodname:op_Explicit
--singlemethodindex:13

We think we are emitting i32.trunc_sat_f32_s which should be 0xfc00...

This is the case we noted earlier where representing opcodes the way we do leads to ambiguity as to whether this is a 1-byte or 2-byte opcode. Here we just emit the 0xFC.

runtime/src/coreclr/jit/instrswasm.h

Line 224 in aeffb4c

INST(i32_trunc_sat_f32_s, "i32.trunc_sat_f32_s", 0, IF_OPCODE, 0x00FC)

(7) invalid local index: 3

(with fixes for 2-5, bailouts for the asserts and (1), and a workaround for (6) we now have 11,000+ methods passing validation).

Dumping functions... #0 S_P_CoreLib_System_Runtime_CompilerServices_AsyncTaskMethodBuilder_1<System___Canon>__SetException ( i32, i32, i32, i32 ) -> none (136 byte(s))

@0277  2000           get_local 0 ; i32 arg0
@0279  4118           i32_const 0x00000018 ; 24
@0281  6B             i32_sub
@0282  2100           set_local 0 ; i32 arg0
@0284  2000           get_local 0 ; i32 arg0
@0286  2001           get_local 1 ; i32 arg1
@0288  360010         i32_store +16
@0291  2000           get_local 0 ; i32 arg0
@0293  2002           get_local 2 ; i32 arg2
@0295  36000C         i32_store +12
@0298  2000           get_local 0 ; i32 arg0
@0300  2003           get_local 3 ; i32 arg3
@0302  360008         i32_store +8
@0305  2000           get_local 0 ; i32 arg0
@0307  2004           get_local 4 ; INVALID local0
@0309  360004         i32_store +4
@0312  2000           get_local 0 ; i32 arg0

Not sure why it changed from 3 to 4, investigating...

Ah we have an incorrect sig here. There are 5 args but we type this as ( i32, i32, i32, i32 ) -> none. This method has a generic context argument, likely we're not accounting for it somewhere.

Guessing this is over on the JIT host side in WasmFuncType -- the method desc sig probably doesn't include the dictionary parameter for generic methods.

Guessing this is over on the JIT host side in WasmFuncType -- the method desc sig probably doesn't include the dictionary parameter for generic methods.

Yeah I haven't seen this accounted for anywhere in any of the code we've written so far. I was assuming it was accounted for elsewhere in the VM as part of the signature.

Asserts hit on debug SPC

Assertion failed 'isInitBlk == src->gtSkipReloadOrCopy()->IsInitVal()'

Single method repro args:--singlemethodtypename "System.Array" --singlemethodname "Ctor" --singlemethodindex 2
C:\repos\runtime2\src\coreclr\jit\gentree.h:9528
Assertion failed 'isInitBlk == src->gtSkipReloadOrCopy()->IsInitVal()' in 'System.Array:Ctor(ptr,uint,ptr):System.Array' during 'Linear scan register alloc' (IL size 25; hash 0xfb8a8728; MinOpts)

In the above the IR node is

N006 (???,???) [000007] --CXG+-----                    t7 = *  CALL r2r_ind int    System.Runtime.CompilerServices.ObjectHandleOnStack:Create[System.__Canon](byref):System.Runtime.CompilerServices.ObjectHandleOnStack
                                                            /--*  t7     int
N007 (???,???) [000016] DACXG+-----                         *  STORE_LCL_VAR struct<System.Runtime.CompilerServices.ObjectHandleOnStack, 4> V10 tmp3

and we seem to have an assumption that if the source of a block store is TYP_INT then the source must be an INIT_VAL.

Looking at this one it seems like it's just an existing bug in the JIT that isn't specific to wasm. I'm not sure what the fix is offhand. I could remove the assert, but I think that's wrong and the assert is flagging that this TYP_INT check is the wrong way to identify an initblk. Is there some non-obvious reason why the check in the assert isn't the check we actually do?

New assert from release SPC I'm seeing locally:

This looks similar/same as #125756 (comment) -- a bit more detail there.

[Wasm RyuJIT] Partially implement genStructReturn (#126326)

Now seeing in release SPC:
Assertion failed '(temporaryRegs.Count == 0) && "Some temporary regs were not consumed/released"' 
in System.ValueTuple`4[System.__Canon,System.__Canon,System.__Canon,System.__Canon]:System.IComparable.CompareTo(System.Object):int:this' 
during 'Linear scan register alloc' (IL size 44; hash 0x5cb9412b; FullOpts)
repro:
--singlemethodtypename:System.ValueTuple`4[[System.__Canon],[System.__Canon],[System.__Canon],[System.__Canon]]
--singlemethodname:System.IComparable.CompareTo
--singlemethodindex:1
Here we have an ADD as the dest of a block store, that we rewrite to a write barrier call. We mark it as multiply used in lower, but never collect up the references later on.
snipped
So this store is nonfaulting and we don't need to request a temp for the dest.

Seems like this similar to the issue referred to here, though the twist here is that we generate a write barrier call.

runtime/src/coreclr/jit/lowerwasm.cpp

Lines 228 to 234 in 51cfb0e

Speaking of write barriers, if we want them to have a simplified calling convention (no $sp) then we must do any null checks beforehand, as they will be unable to throw an exception.

I have a fix for this but it breaks other stuff. Will keep poking at it, but I feel like it should 'just work' to request temporaries in this case. Optimizing out the temporary for every single possible scenario is going to make the code for this complex and fragile.

With local changes to turn the last few asserts into NYIs, here's where we're at for release S.P.CoreLib:

NYI_WASM: genFuncletProlog
NYI_WASM: genCallFinally
NYI_WASM: Opcode not implemented (CATCH_ARG)
NYI_WASM: alloc local frame for reverse pinvoke
NYI_WASM: emit.h:3925
NYI_WASM: gentree.cpp:16961

There are around 1500 NYIs in total and most of them look like EH. Presumably once EH is implemented we'll see more failures crop up in the code that's hidden inside EH-containing methods.

[Wasm RyuJIT] Set wasm's vector width to 128 bits (#126375)

[Wasm RyuJIT] Fix for assert in obscure block store scenario (#126392)

With recent changes to RA there are new fairly common asserts (representative samples here)

Z:\runtime\src\coreclr\jit\codegenwasm.cpp:1341
Assertion failed 'WasmRegToType(resultReg) == TypeToWasmValueType(treeNode->TypeGet())' in 'System.Exception:ToString():System.String:this' during 'Generate code' (IL size 333; hash 0x8c190874; FullOpts)

Z:\runtime\src\coreclr\jit\codegenwasm.cpp:1374
Assertion failed 'WasmRegToType(resultReg) == TypeToWasmValueType(treeNode->TypeGet())' in 'System.Byte:System.Numerics.IDecrementOperators<System.Byte>.op_CheckedDecrement(byte):byte' during 'Generate code' (IL size 8; hash 0xa6822aa8; FullOpts)

Z:\runtime\src\coreclr\jit\codegenwasm.cpp:1411
Assertion failed 'WasmRegToType(wideReg) == WasmValueType::I64' in 'System.Byte:System.Numerics.IMultiplyOperators<System.Byte,System.Byte,System.Byte>.op_CheckedMultiply(byte,byte):byte' during 'Generate code' (IL size 5; hash 0x09424ece; FullOpts)

Z:\runtime\src\coreclr\jit\gentree.h:1071
Assertion failed '(gtRegTag == GT_REGTAG_NONE) || genIsValidReg(reg) || (reg == REG_COUNT)' in 'System.StubHelpers.CSTRMarshaler:ConvertToNative(int,System.String,nint):nint' during 'Linear scan register alloc' (IL size 194; hash 0x949c850d; FullOpts)

Z:\runtime\src\coreclr\jit\codegenwasm.cpp:576
Assertion failed 'genIsValidReg(reg)' in 'System.StubHelpers.CSTRMarshaler:ConvertToNative(int,System.String,nint):nint' during 'Generate code' (IL size 194; hash 0x949c850d; FullOpts)

Z:\runtime\src\coreclr\jit\registeropswasm.cpp:187
Assertion failed '(WasmValueType::Invalid < wasmType) && (wasmType < WasmValueType::Count)' in 'System.StubHelpers.CSTRMarshaler:ConvertToNative(int,System.String,nint):nint' during 'Generate code' (IL size 194; hash 0x949c850d; FullOpts)

Plus some that don't look related to the RA changes

Z:\runtime\src\coreclr\jit\importer.cpp:783
Assertion failed 'store->TypeGet() == src->TypeGet()' in 'System.Nullable`1[System.Reflection.Metadata.TypeNameParseOptions]:op_Explicit(System.Nullable`1[System.Reflection.Metadata.TypeNameParseOptions]):System.Reflection.Metadata.TypeNameParseOptions' during 'Lowering nodeinfo' (IL size 8; hash 0xbc4e1b69; FullOpts)

Z:\runtime\src\coreclr\jit\gentree.cpp:700
Assertion failed 'varTypeIsStruct(TypeGet())' in 'System.Nullable`1[System.Reflection.Metadata.TypeNameParseOptions]:op_Explicit(System.Nullable`1[System.Reflection.Metadata.TypeNameParseOptions]):System.Reflection.Metadata.TypeNameParseOptions' during 'Lowering nodeinfo' (IL size 8; hash 0xbc4e1b69; FullOpts)

Z:\runtime\src\coreclr\jit\gentree.cpp:734
Assertion failed 'unreached' in 'System.Nullable`1[System.Reflection.Metadata.TypeNameParseOptions]:op_Explicit(System.Nullable`1[System.Reflection.Metadata.TypeNameParseOptions]):System.Reflection.Metadata.TypeNameParseOptions' during 'Lowering nodeinfo' (IL size 8; hash 0xbc4e1b69; FullOpts)

For the first one above we're collecting references in a node more than once, since the requests are not adjacent in time:

Requesting internal int register for [000266]
Collected [000266]
Collected [000265]
Consumed a temporary reg for [000265]: binop overflow check
Collected [000263]
Consumed a temporary reg for [000263]: binop overflow check
Requesting internal int register for [000267]
Collected [000267]
Collected [000266]
Consumed a temporary reg for [000266]: binop overflow check

[Wasm RyuJIT] Fix for assert in obscure block store scenario (dotnet#…

[Wasm RyuJit] fix funclet prolog and epilog codegen (#126663)

Believe these are all fixed now.

Navigation Menu

Repository navigation

[Wasm RyuJit] asserts crossgenning wasm debug SPC #125756

Debug SPC Asserts

(1) Assertion failed 'isInitBlk == src->gtSkipReloadOrCopy()->IsInitVal()'

(2) Assertion failed 'emitTypeSizes[TypeGet(type)] > 0'

Debug SPC Wasm Validation Errors

(1) not enough arguments on the stack for memory.copy (need 3, got 2)

(2) i64.shl[1] expected type i64, found i32.const of type i32

(3) call_indirect[2] expected type i64, found i32.load of type i32

(4) i64.and[0] expected type i64, found i64.eq of type i32

(5) i32.clz[0] expected type i32, found i64.load of type i64

More Debug SPC Wasm Validation Errors

(6) invalid numeric opcode: 0xfc41

(7) invalid local index: 3

Assertion failed 'isInitBlk == src->gtSkipReloadOrCopy()->IsInitVal()'

23 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// TODO-WASM: Zero-extend the 2nd operand for shifts and rotates as needed when the 1st and 2nd operand are
	// different types. The shift operand width in IR is always TYP_INT; the WASM operations have the same widths
	// for both the shift and shiftee. So the shift may need to be extended (zero-extended) for TYP_LONG.

[Wasm RyuJit] asserts crossgenning wasm debug SPC #125756

Description

Debug SPC Asserts

(1) Assertion failed 'isInitBlk == src->gtSkipReloadOrCopy()->IsInitVal()'

(2) Assertion failed 'emitTypeSizes[TypeGet(type)] > 0'

Activity

AndyAyersMS commented on Mar 18, 2026

AndyAyersMS commented on Mar 19, 2026

Debug SPC Wasm Validation Errors

(1) not enough arguments on the stack for memory.copy (need 3, got 2)

(2) i64.shl[1] expected type i64, found i32.const of type i32

(3) call_indirect[2] expected type i64, found i32.load of type i32

(4) i64.and[0] expected type i64, found i64.eq of type i32

(5) i32.clz[0] expected type i32, found i64.load of type i64

kg commented on Mar 19, 2026

AndyAyersMS commented on Mar 19, 2026

AndyAyersMS commented on Mar 19, 2026

AndyAyersMS commented on Mar 19, 2026

More Debug SPC Wasm Validation Errors

(6) invalid numeric opcode: 0xfc41

(7) invalid local index: 3

kg commented on Mar 20, 2026

kg commented on Mar 20, 2026

Assertion failed 'isInitBlk == src->gtSkipReloadOrCopy()->IsInitVal()'

23 remaining items

AndyAyersMS commented on Mar 31, 2026

kg commented on Mar 31, 2026

kg commented on Apr 1, 2026

kg commented on Apr 8, 2026

AndyAyersMS commented on Apr 8, 2026

AndyAyersMS commented on Apr 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions