sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/telemetry: consolidate gopls's cmd/stacks with watchflakes
Labels: NeedsFix,telemetry,Friction

This issue is following up on a team discussion. Filing to make sure we capture context.

We've been using [golang.org/x/tools/gopls/internal/telemetry/cmd/stacks](https://pkg.go.dev/golang.org/x/tools/gopls/internal/telemetry/cmd/stacks) to produce and de-dupe the issues filed under the [gopls/telemetry-wins](https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+label%3Agopls%2Ftelemetry-wins) label.

This command parses, formats, linkifies, and de-dupes stack traces appearing in telemetry data. For "new" stacks, it pops open a window to file a github issue. Recently, @adonovan added predicate-based [deduplication](https://go.dev/cl/613215), similar to watchflakes.

Now we have stacks coming from more than just gopls: the `compile/bug` stack counter has been appearing in recent data ([example](https://storage.googleapis.com/prod-telemetry-merged/2024-10-10.json)).
We should generalize the stacks command. It has been suggested to merge it with watchflakes, since the two serve similar functionality.

Here are some barriers to this automation:

1. The stacks command does git-clone and build of the various executables as that's the only way to get the correct pclntab required to map the symbol-relative line numbers into absolute CodeSearch URLs
2. Running the command sometimes results in errors in which two issues "claim" the same stack due to overlapping rules. In this case one or both of the rules should be updated and the tool re-run.
3. When no existing issue claims the stack, the command opens a browser tab with a populated "New issue" form. At this point the triageur is expected to see if it looks like a real new issue or a dup. If a dup, the existing issue's rule should be updated and the tool re-run. If not, then the user should submit the form to create the new issue.
4. when creating the new issue, it's a good idea to choose a more specific title and to copy some of the surrounding code (e.g. the call to bug.Report) into the issue body. I suppose that could be done later by the triageur. Or automated with better heuristics and logic.
Repository: PowerToys
Issue: Peek Configuration Documentation and Perceived Types
Labels: Issue-Docs,Needs-Triage

### Provide a description of requested docs changes

I haven't been able to find anything in the Peek documentation, but I wonder if I am overlooking some key information:

If I want File Explorer -- specifically, Preview Pane -- to handle new file types/extensions as text-encoded when displaying a preview for that particular extension, I can find the entry in the Registry for a given extension and add a perceived type value of `text`. By contrast, the same registry value (that has worked consistently in File Explorer) does **not** control Peek's behavior.

Could someone please shed some light on whether a similar solution is available for Peek?  Is there a value that can be added/modified in the respective JSON settings file to achieve the same result?  So many file extensions that are really just plain text files, cannot be previewied in Peek unless the file extension is changed to txt (or some other extension Peek recognizes as a text-encoded filetype).
Repository: godot
Issue: Shader compile error and subsequent crash on Radeon 3000
Labels: bug,platform:windows,topic:core,topic:rendering,topic:thirdparty

### Tested versions

Reproducible in Godot 4.3 stable
Not Reproducible Godot 3.6 stable

### System information

Windows 10 - Godot 4.3 stable - OpenGL Compatibility - Athlon II 260 with integrated ATI Radeon 3000

### Issue description

Just running Godot 4.3 logs shader compile errors then crashes:
Ran from cmd prompt and copy and pasted output to godot_cmd.log:
[godot_cmd.log](https://github.com/user-attachments/files/17467358/godot_cmd.log)

At the very least it would be nice for the user to get the error message that says to try updating drivers. I submitted that as a Godot Proposal: https://github.com/godotengine/godot-proposals/issues/11008


### Steps to reproduce

1. Download Godot x86_64 4.3 for Windows
2. Run in cmd prompt 
3. A black window briefly shows and then disappears


### Minimal reproduction project (MRP)

No project needed, just try to run Godot 4.3
Repository: go
Issue: cmd/cgo/internal/test: unrecognized failures [consistent failure]
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "cmd/cgo/internal/test" && test == ""
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8733445799417074081)):

    FAIL	cmd/cgo/internal/test [build failed]


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: cmd/cgo/internal/testerrors: TestPointerChecks failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "cmd/cgo/internal/testerrors" && test == "TestPointerChecks"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8733443699298031025)):

    === RUN   TestPointerChecks
        ptr_test.go:619: go build: exit status 1
            # ptrtest
            /opt/golang/swarm/.swarming/w/ir/x/w/goroot/pkg/tool/solaris_amd64/link: running gcc failed: exit status 1
            /usr/bin/gcc -m64 -Wl,--build-id=0x5c0bc9f5b8a0cc1596219e4a9b290d7941bd0d78 -o $WORK/b001/exe/a.out -rdynamic -Wl,--compress-debug-sections=zlib /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/go.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000000.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000001.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000002.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000003.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000004.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000005.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000006.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000007.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000008.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000009.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000010.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000011.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-1131729686/000012.o -O2 -g -O2 -g -lxnet -lsocket -lsendfile -no-pie
            ld: fatal: unrecognized option --build-id=0x5c0bc9f5b8a0cc1596219e4a9b290d7941bd0d78
            ld: fatal: use the '-z help' option for usage information
            collect2: error: ld returned 1 exit status
            
    --- FAIL: TestPointerChecks (3.84s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: cmd/cgo/internal/testerrors: TestReportsTypeErrors failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "cmd/cgo/internal/testerrors" && test == "TestReportsTypeErrors"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8733438446787498161)):

    === RUN   TestReportsTypeErrors
        errors_test.go:111: `go run testdata/long_double_size.go`: exit status 1:
            # command-line-arguments
            /opt/golang/swarm/.swarming/w/ir/x/w/goroot/pkg/tool/solaris_amd64/link: running gcc failed: exit status 1
            /usr/bin/gcc -m64 -s -Wl,--build-id=0x129c1ba039253aeae23c5cb5cf1383785c1453fb -o $WORK/b001/exe/long_double_size -rdynamic -Wl,--compress-debug-sections=zlib /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/go.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000000.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000001.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000002.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000003.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000004.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000005.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000006.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000007.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000008.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000009.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000010.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-2106502879/000011.o -O2 -g -O2 -g -lxnet -lsocket -lsendfile -no-pie
            ld: fatal: unrecognized option --build-id=0x129c1ba039253aeae23c5cb5cf1383785c1453fb
            ld: fatal: use the '-z help' option for usage information
            collect2: error: ld returned 1 exit status
            
    --- FAIL: TestReportsTypeErrors (1.85s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: cmd/cgo/internal/testfortran: TestFortran failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "cmd/cgo/internal/testfortran" && test == "TestFortran"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8733434853156215457)):

    === RUN   TestFortran
        fortran_test.go:63: CGO_LDFLAGS= -L /usr/gcc/11/lib/amd64 -Wl,-rpath,/usr/gcc/11/lib/amd64
        fortran_test.go:70: /usr/bin/gfortran [testdata/helloworld/helloworld.f90 -o /dev/null]
        fortran_test.go:76: go run ./testdata/testprog
        fortran_test.go:82: /opt/golang/swarm/.swarming/w/ir/x/w/goroot/bin/go run ./testdata/testprog
        fortran_test.go:84: stderr:
            # cmd/cgo/internal/testfortran/testdata/testprog
            /opt/golang/swarm/.swarming/w/ir/x/w/goroot/pkg/tool/solaris_amd64/link: running gcc failed: exit status 1
            /usr/bin/gcc -m64 -s -Wl,--build-id=0x614d1abbf20fce211b9d95e98d2b6500b2ea031d -o $WORK/b001/exe/testprog -rdynamic -Wl,--compress-debug-sections=zlib /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/go.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000000.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000001.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000002.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000003.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000004.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000005.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000006.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000007.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000008.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000009.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000010.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000011.o /opt/golang/swarm/.swarming/w/ir/x/t/go-link-3193556920/000012.o -L /usr/gcc/11/lib/amd64 -Wl,-rpath,/usr/gcc/11/lib/amd64 -lgfortran -L /usr/gcc/11/lib/amd64 -Wl,-rpath,/usr/gcc/11/lib/amd64 -lxnet -lsocket -lsendfile -no-pie
            ld: fatal: unrecognized option --build-id=0x614d1abbf20fce211b9d95e98d2b6500b2ea031d
            ld: fatal: use the '-z help' option for usage information
            collect2: error: ld returned 1 exit status
            
        fortran_test.go:87: exit status 1
    --- FAIL: TestFortran (4.73s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: rust
Issue: Unmerged stack slots under Windows
Labels: A-LLVM,A-codegen,T-compiler,O-windows-msvc,I-heavy,C-optimization

https://godbolt.org/z/1foPhW5PT

Relevant bits:
```asm
example::write_characteristics::hd20ef966b954cd90:
        sub     rsp, 200
```
```llvm
define void @example::write_characteristics::hd20ef966b954cd90(i16 noundef %c) unnamed_addr {
start:
  %0 = alloca [16 x i8], align 8
  %1 = alloca [16 x i8], align 8
  %2 = alloca [16 x i8], align 8
  %3 = alloca [16 x i8], align 8
  %4 = alloca [16 x i8], align 8
  %5 = alloca [16 x i8], align 8
  %6 = alloca [16 x i8], align 8
  %7 = alloca [16 x i8], align 8
  %8 = alloca [16 x i8], align 8
  %9 = alloca [16 x i8], align 8
```

I think all the allocas should've been merged in one, or be able to pass a pointer to a global const with the slice.
Repository: ui
Issue: [bug]: Label for disabled RadioGroupItem not showing as disabled
Labels: bug

### Describe the bug

![image](https://github.com/user-attachments/assets/acaa1d74-7668-4821-b890-b9ecefaf531a)

The "peer" class is missing for `RadioGroupPrimitive.Item` in `RadioGroupItem` for this to work like the checkbox.
Last radio group item is modified with the "peer" class. The others are as is.

### Affected component/components

RadioGroupItem

### How to reproduce

1. go to https://ui.shadcn.com/docs/components/radio-group
2. look at code for manual installation
3. notice that "peer" class is missing :shrug

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
-
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: vscode
Issue: enable the edit > show writing tools menu for editor
Labels: bug,macos,electron

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

On macOS with Apple Intelligence enabled, most third-party applications display the "Writing Tools" menu option in the edit menu, providing writing suggestions and proofreading options. For those writing documentations in vscode, enabling this menu could prove beneficial.

e.g. here's the menu in google chrome,

![Image](https://github.com/user-attachments/assets/ffb50ba0-5e59-42a4-8309-567100980e0f)
Repository: pytorch
Issue: SDPA: CUDNN backend error w/ q_seq_len = 1
Labels: module: cuda,triaged,module: sdpa

## Summary

Repro script
``` Python
import torch
import torch.nn as nn
import torch.nn.functional as F


q = torch.randn(1, 16, 1, 64, device="cuda", dtype=torch.bfloat16, requires_grad=True)
k = torch.randn(1, 16, 2**16, 64, device="cuda", dtype=torch.bfloat16, requires_grad=True)
v = torch.randn(1, 16, 2**16, 64, device="cuda", dtype=torch.bfloat16, requires_grad=True)


from torch.nn.attention import sdpa_kernel, SDPBackend    

with sdpa_kernel(SDPBackend.CUDNN_ATTENTION):
    out = F.scaled_dot_product_attention(q, k, v)
    out.backward(torch.ones_like(out))

```

Error:
``` Shell
/home/drisspg/meta/pytorch/torch/autograd/graph.py:825: UserWarning: cuDNN SDPA backward got an innermost stride of 0 in grad_out, which is unsupported. Materializing a contiguous tensor which will increase memory usage... (Triggered internally at /home/drisspg/meta/pytorch/aten/src/ATen/native/cudnn/MHA.cpp:664.)
  return Variable._execution_engine.run_backward(  # Calls into the C++ engine to run the backward pass
Traceback (most recent call last):
  File "/home/drisspg/meta/scripts/sdpa/repro_gqa.py", line 15, in <module>
    out.sum().backward()
  File "/home/drisspg/meta/pytorch/torch/_tensor.py", line 624, in backward
    torch.autograd.backward(
  File "/home/drisspg/meta/pytorch/torch/autograd/__init__.py", line 347, in backward
    _engine_run_backward(
  File "/home/drisspg/meta/pytorch/torch/autograd/graph.py", line 825, in _engine_run_backward
    return Variable._execution_engine.run_backward(  # Calls into the C++ engine to run the backward pass
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: cuDNN Frontend error: [cudnn_frontend] Error: No execution plans support the graph.
```

cc @ptrblck @msaroufim @eqy @mikaylagawarecki
Repository: godot
Issue: Export variables don't start filled on Instantiate
Labels: topic:core,needs testing

### Tested versions

## Tested versions
Reproducible in: v4.3.stable.mono.official

### System information

Godot v4.3.stable.mono - Windows 10.0.22631 - GLES3 (Compatibility) - AMD Radeon RX 6600 (Advanced Micro Devices, Inc.; 32.0.12011.1036) - AMD Ryzen 7 5700X 8-Core Processor (16 Threads)

### Issue description

![image](https://github.com/user-attachments/assets/a584b519-11e6-41be-b3a2-42c8c663dd7c)
I have this scene with a RigidBody2D. In its script I exported a RigidBody2D and assign the very same RigidBody2D (yeah, the way I have implemented that script need to be done in that way). In **another script** I Instantiate this **IceAndFireFx** via code (C#), but the exported RigidtBody2D variable starts null.

I saw this thread #87837 but it was closed without any solution. Looks like it was closed coz the admin missunderstood the problem. But now I'm facing the same issue.

### Steps to reproduce

- Create a Scene
- Attach a C# script with a Exported variable
- Attatch the script owner to the Exported variable
- Instantiate via code the scene with the Exported variable filled
- Get a null exported variable after instantiate.

### Minimal reproduction project (MRP)

[bugreport.zip](https://github.com/user-attachments/files/17468193/bugreport.zip)
Repository: bitcoin
Issue: getblockchaininfo `verificationprogress` never reaches 1.0
Labels: RPC/REST/ZMQ

In the output of `bitcoin-cli getblockchaininfo`, `verificationprogress` sometimes never reaches 1.0, and fluctuates around 0.99999.

```
{
  ...
  "verificationprogress": 0.9999945316157191,
  ...
}
```

This was reported in #26433, and closed because `verificationprogress` is only an estimate. I would have commented in that issue, but it's locked. The rationale for closing the issue was because the OP in the issue wanted to use `verificationprogress` to check if the chain is synced, and the field is only an estimate, and shouldn't be relied on as exact.

This makes sense, however, however, I think it still should be fixed so that, at the chain tip, `verificationprogress` is 1.0, just for UX reasons. Many a time I've looked at the output of `getblockchaininfo` and been confused because it isn't at 1.0.
Repository: rust
Issue: rustc 1.82.0 doesn't add LIBPATH when invoking link.exe
Labels: A-linkage,T-compiler,O-windows-msvc,C-discussion

Rust-to-rust dynamic linking (through import library) on Windows fails with toolchain version 1.82.0. 

The build log shows that 1.82.0 is not adding any /LIBPATH arguments when invoking link.exe.


I tried this code: [nandin-borjigin/rustc-1.82.0-repro](https://github.com/nandin-borjigin/rustc-1.82.0-repro)

![Image](https://github.com/user-attachments/assets/cafb5b8c-4229-4a74-8ff8-8821d320fae4)


I expected to see this happen: *Successful build*

Instead, this happened: *LINK : fatal error LNK1181: cannot open input file 'mylib.dll.lib'*

![Image](https://github.com/user-attachments/assets/a9f0bdf1-f49d-4667-bbb1-5325474fbf9a)

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-pc-windows-msvc
release: 1.82.0
LLVM version: 19.1.1
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

</p>
</details>

### Possibly related

- #131995
Repository: kubernetes
Issue: Enhancement for ExecAction in Pod Lifecycle
Labels: sig/node,kind/feature,needs-triage

### What would you like to be added?

Currently the the ExecAction in Pod Lifecycle does not support timeout and the hardcode when run in the container. Suggest adding a timeout param fo ExecAction.

* https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json
```
"io.k8s.api.core.v1.ExecAction": {
      "description": "ExecAction describes a \"run in container\" action.",
      "properties": {
        "command": {
          "description": "Command is the command line to execute inside the container, the working directory for the command  is root ('/') in the container's filesystem. The command is simply exec'd, it is not run inside a shell, so traditional shell instructions ('|', etc) won't work. To use a shell, you need to explicitly call out to that shell. Exit status of 0 is treated as live/healthy and non-zero is unhealthy.",
          "items": {
            "type": "string"
          },
          "type": "array",
          "x-kubernetes-list-type": "atomic"
        }
      },
      "type": "object"
    }
```
* https://github.com/kubernetes/kubernetes/blob/9d967ff97332a024b8ae5ba89c83c239474f42fd/pkg/kubelet/lifecycle/handlers.go#L72-L80

### Why is this needed?

If PostStart uses ExecAction and exec hangs during execution, the container call will hang. If the timeout is supported, users can force-stop the container based on the timeout.

### Labels:
/sig sig-api-machinery
/wg wg-api-expression
Repository: excalidraw
Issue: Uncaught SyntaxError: Invalid Regular expression
Labels: bug

> excalidraw.production.js:2 Uncaught SyntaxError: Invalid regular expression: /^[^A-Za-zÃ€-Ã–Ã˜-Ã¶Ã¸-Ê¸Ì€-Öà €-á¿¿â°€-ï¬œï·¾-ï¹¯ï»½-ï¿¿]*[Ö‘-ß¿ï¬-ï·½ï¹°-ï»¼]/: Range out of order in character class

I am trying to use the production library in a chrome browser extension but I am getting this error when the extension loads.
Repository: material-ui
Issue: AvatarGroup +n icon's default colors do not meet minimum contrast ratio threshold for accessibility
Labels: accessibility,component: avatar,enhancement

### Steps to reproduce

Link to live example: (required)
Every (+n) avatar on https://mui.com/material-ui/react-avatar/

Steps:
1. Visit the link above.
2. Run the axe Devtools chrome extension accessibility scan on that page.
3. Every (+n) avatar on the page gets flagged as not meeting the contrast ratio (in both light and dark mode, though I have screenshotted light mode for this particular example):
<img width="1690" alt="image" src="https://github.com/user-attachments/assets/4caeb893-4df7-41a2-8cfb-209acce5ee2c">



### Current behavior

Axe devtools highlights all the (+n) avatars, with the message: Element has insufficient color contrast of 1.87 (foreground color: #ffffff, background color: #bdbdbd, font size: 15.0pt (20px), font weight: normal). Expected contrast ratio of 4.5:1

### Expected behavior

The default colors on (+n) avatars should have a high enough contrast ratio to pass the accessibility scan.

### Context

I am trying to fix accessibility issues on my site, and while I could override the avatar colors on my own, it seems worthwhile to make the default colors pass accessibility tests out of the box.

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: macOS 12.7.6
  Binaries:
    Node: 20.11.0 - ~/.nvm/versions/node/v20.11.0/bin/node
    npm: 10.2.4 - ~/.nvm/versions/node/v20.11.0/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: 130.0.6723.59
```
</details>

This bug is likely system agnostic though since it is a default colors accessibility issue that can be seen on the mui website.

**Search keywords**: avatargroup default colors accessibility