GreptimeDB Fuzz CI Failure Investigation

Investigate failed fuzz-test jobs for GreptimeTeam/greptimedb from a local checkout. The purpose is to download the failed job's CI output and fuzz artifacts, then explain the likely cause by correlating the evidence with GreptimeDB source.

Always pass --repo GreptimeTeam/greptimedb to gh; local remotes may point to forks. Keep the workflow read-only: do not rerun jobs, cancel workflows, push, comment on PRs, or delete artifacts unless the user explicitly asks.

Scope

Use this skill for fuzz CI only. In .github/workflows/integration.yml, fuzz failures are the CI jobs that use .github/actions/fuzz-test:

• fuzztest, standalone fuzz targets.
• unstable-fuzztest, unstable standalone fuzz target.
• distributed-fuzztest, distributed cluster fuzz targets.
• distributed-fuzztest-with-chaos, distributed fuzz targets with Chaos Mesh.

Each matrix job runs a semantic group of targets on one prepared environment. The group defaults to fail-fast: after the first target failure it captures that target's diagnostics and marks the remaining targets as skipped. The workflow strategy still uses fail-fast: false, so failures do not cancel other groups.

The reusable action .github/actions/fuzz-test/action.yaml delegates each target to .github/scripts/run-fuzz-targets.sh. CI passes FUZZ_BIN_DIR, so the script runs the prebuilt target executable:

<prebuilt-fuzz-binary> -max_total_time=<seconds> \
  -artifact_prefix=<target-dir>/libfuzzer/

Without FUZZ_BIN_DIR, such as during local reproduction, the script falls back to cargo fuzz run <target> --fuzz-dir tests-fuzz -D -s none with the same libFuzzer arguments.

Failed jobs upload one group artifact. Its stable name identifies the job kind, mode, and group, for example:

fuzz-distributed-remote-wal-database-and-regular-table