Fuzz: "==5845== ERROR: libFuzzer: timeout after 1272 seconds" (ubuntu-latest)

[github-actions]

The fuzz-testing workflow has detected a bug.

Auto-Minimized Fuzzing Input That Triggers the Bug: Click this line.

Note: If the input is multi-line then the end-of-line characters ' ' (0x0A) and ' ' (0x0D) may affect the reproducibility of the bug. If you fail to repro the bug with the input shown below then you may want to go to the workflow that reported this GitHub bug, download the artifact, and extract the file with the exact minimized input.

(Input minimization failed, see the workflow logs and artifacts)

The branch/commit the bug has been found in: Click.

If the developers fail to repro the bug in the latest main then the branch/commit info below can help them to make sure that they are using the correct way to repro. If the bug is reproducible in the branch/commit below, but not in latest main, then the bug is likely fixed already or is not in the main branch.

Branch: * main

commit edebe14a60c88561c2453670964066a151333289
Author: Stefan J. Wernli <swernli@microsoft.com>
Date:   Fri Mar 27 09:37:50 2026 -0700

    Support `NoiseConfig` for Q# and OpenQASM on sparse simulation (#3062)
    
    This change supports granular noise configuration for the mechanisms
    that use sparse state simulator, namely `qsharp.run` and `openqasm.run`.
    This brings it up to parity with our QIR-based simulation in the
    `NeutralAtomDevice` on cpu and gpu (and clifford).

Other Info

• Workflow (contains the run artifacts).
• Workflow Agent System Info: ubuntu-latest: Linux runnervmrg6be 6.17.0-1008-azure #8~24.04.1-Ubuntu SMP Mon Jan 26 18:35:40 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux.

[swernli]

this looks like another instance of the on-again, off-again OpenQASM timeouts and memory issues we see with const expression evaluation.

[idavis]

@orpuente-MS If this is const eval, we should look to make sure const eval isn't run if there were parse errors. Might also be worth adding some guard conditions. Left shifting 100MM times isn't something we should do ;)

_ [_ :66>>666666666666666&6>>666666666&666&66666666&666<666&66666<66666&333661<46666>5 :,:5 :^,5666<666&66666<66666&3333326&6>>666666666&666&66666666&666<666&66666<66666&333661<46666>5 :,:5 :^,5666<666&66666<66666&333332&661<46666>5d:,:5 :^,5:3:_

[orpuente-MS]

Two comments on this:

1. We can still hit this if there are no parse errors, since the cause here is the huge const-time computation, not the parse errors themselves.
2. Const-eval needs to run to determine the types of sized-types. Not running const-eval means giving up on type-checking for sized-types, which probably means giving up on type checking altogether if there are parse errors. I'm not sure if we are OK with that given that we have followed a best-effort compilation approach until now, and it feels weird giving up on that just because of the fuzzer.

EDIT: I just read the "adding guard conditions" part. That should solve the fuzzer issue.