# Greptimedb Fuzz Ci Failure Investigation

Investigate a failed GreptimeDB fuzz CI target link by downloading GitHub Actions job...

- Repository: https://github.com/GreptimeTeam/greptimedb (6778 stars)
- Category: Git and review
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add GreptimeTeam/greptimedb --skill greptimedb-fuzz-ci-failure-investigation -g -a claude-code -y`
Codex: `npx skills add GreptimeTeam/greptimedb --skill greptimedb-fuzz-ci-failure-investigation -g -a codex -y`
Cursor: `npx skills add GreptimeTeam/greptimedb --skill greptimedb-fuzz-ci-failure-investigation -g -a cursor -y`
Gemini CLI: `npx skills add GreptimeTeam/greptimedb --skill greptimedb-fuzz-ci-failure-investigation -g -a gemini-cli -y`

## Description

Investigate a failed GreptimeDB fuzz CI target link by downloading GitHub Actions job logs plus fuzz artifacts such as kind logs, monitor dumps, and CSV dumps, then correlate the failure with local GreptimeDB source code. Use when the user provides a failed fuzz CI target/job URL or asks to diagnose GreptimeDB fuzz CI failures.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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:

```bash
<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:

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

The rest: https://github.com/GreptimeTeam/greptimedb/blob/HEAD/.agents/skills/greptimedb-fuzz-ci-failure-investigation/SKILL.md