mcpField
V
verify

verify

github.com/redisearchTesting & quality6.2k46 installsUpdated today
Repository

About verify

A verification skill for contributors preparing code changes for commit or a pull request. It selects build, test, formatting, and safety checks based on whether C, Rust, or both were changed.

Key features

  1. 01Select checks based on changed languages
  2. 02Run C build and unit tests
  3. 03Run Rust formatting, lint, and tests
  4. 04Verify memory-safety fixes against pre-fix code
  5. 05Run behavioral and coordinator tests when applicable

Use cases

  1. 01Verify C or Rust changes before a commit
  2. 02Check a claimed memory-safety fix
  3. 03Validate coordinator changes in a cluster

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/redisearch/redisearch --skill verify

After installing, type/verifyin Claude Code to confirm it loaded.

Details

From the project README

Verify Skill

Run full verification before committing or creating a PR.

Usage

Use this skill to run comprehensive checks before finalizing changes.

Instructions

Determine which code was modified (C, Rust, or both) and run the appropriate checks.

If dependencies, .install/, bootstrap targets, toolchain versions, or CI provisioning changed, first follow Bootstrap and Dependency Changes.

If C code was modified

Run the following checks in order:

1. Build
./build.sh

Ensure the full project compiles without warnings promoted to errors.

2. C/C++ Unit Tests
./build.sh RUN_UNIT_TESTS ENABLE_ASSERT=1

All unit tests must pass. Use /run-c-unit-tests for details on running specific tests.

3. Behavioral Tests
./build.sh RUN_PYTEST ENABLE_ASSERT=1

Required for changes to command handlers, query execution, indexing pipeline, or RDB serialization.

4. AddressSanitizer (recommended for memory-related changes)
./build.sh RUN_UNIT_TESTS SAN=address

If the change claims to fix a memory-safety bug, also follow Memory-safety fixes (either language) below.

5. Coordinator Tests (if coord/ code was modified)

Changes to the coordinator (src/coord/), distributed hybrid (src/coord/hybrid/), or the Map-Reduce layer (src/coord/rmr/) must be tested in a clustered environment:

./build.sh RUN_PYTEST ENABLE_ASSERT=1 REDIS_STANDALONE=0 SHARDS=3

This spins up a 3-shard cluster and runs the full test suite against it.

If Rust code was modified
1. Format Check
make fmt CHECK=1

If it fails, run make fmt to fix formatting.

2. Lint Check
make lint

Fix any clippy warnings or errors.

3. Build
./build.sh

Ensure the full project compiles.

4. Rust Tests
cargo nextest run --manifest-path src/redisearch_rs/Cargo.toml

All Rust tests must pass.

If the change claims to fix a memory-safety bug, also follow Memory-safety fixes (either language) below.

If both C and Rust were modified

Run all checks from both sections above.

Memory-safety fixes (either language)

When the change claims to fix a memory-safety bug (out-of-bounds access, use-after-free), demonstrate the bug once on the pre-fix code with an executed sanitizer repro — a predicted report is not verification. Expect the sanitizer report on the pre-fix code and a clean run on the fixed one.

For C, the cheap form needs no ASan build tree: extract the affected file at the pre-fix revision and compile a standalone repro against it, e.g.

git show HEAD:src/<file>.c > /tmp/before_fix.c           # fix not yet committed (the usual case)
git show <fix-commit>^:src/<file>.c > /tmp/before_fix.c  # fix already committed
clang -fsanitize=address -g -O0 <repro.c> /tmp/before_fix.c -o repro && ./repro

Most src/ files won't compile standalone as-is: expect to add -I paths and stub out heavyweight includes (rm_malloc, RS_ABORT, module headers) with minimal definitions in the repro's own directory. That stubbing is usually minutes of work, not hours.

The repro must build against a consistent pre-fix baseline. If the fix also touches a header, macro, or inline helper the extracted file depends on, extract those at the same pre-fix revision — compiling a pre-fix .c against post-fix headers tests a mixed program that can hide the bug or fail for an unrelated reason. When the dependency set grows past a few files, a worktree checked out at the pre-fix revision is simpler.

For Rust, run the failing case on the pre-fix code under Miri (cargo +nightly miri test --manifest-path src/redisearch_rs/Cargo.toml -p <crate>); for bugs Miri cannot reach (FFI, foreign memory), use an ASan build of the affected test. Single-file extraction does not work here — cargo builds the whole crate — and the current checkout already contains the fix, so a Miri run in it only shows the fixed code is clean. Check out a pre-fix tree first:

git worktree add --detach /tmp/prefix_tree HEAD           # fix not yet committed (the usual case)
git worktree add --detach /tmp/prefix_tree <fix-commit>^  # fix already committed

If the failing test was added alongside the fix, copy the test (and only the test) into that tree. Run Miri or ASan with --manifest-path pointing at the worktree, expect the failure there and a clean run in the fixed checkout, then clean up with git worktree remove --force /tmp/prefix_tree.

Behavioral Tests (for significant changes in either language)
./build.sh RUN_PYTEST ENABLE_ASSERT=1
Showing behavior on a live server

Test suites prove what they assert. To show a user-visible change working on a real redis-server, or to reproduce a report by hand, follow /drive-redisearch.

Quick Verification

For minor Rust-only changes (subshell keeps the chain readable — one cwd hop, three commands):

(cd src/redisearch_rs && cargo fmt --check && cargo clippy --all-targets && cargo nextest run)

For minor C-only changes:

./build.sh && ./build.sh RUN_UNIT_TESTS ENABLE_ASSERT=1

Comments

Markdown supported