본문으로 건너뛰기
cccskills
무료GitHub에 공개

debug-fuzz

Debug failing QuestDB WAL fuzz tests involving column conversions and Parquet partitions. Use seeds and failure logs to trace column and partition history, compare WAL results with a non-WAL baseline, and add temporary state logging without changing the fuzz sequence.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Debug a failing WAL fuzz test involving column conversions and parquet partitions

questdb/questdb스타 17,477(GitHub 17,477 + cccskills 0)

실행 점수 미검증

설치 방법 보기

이럴 때 유용합니다

  • Reproducing a WAL fuzz failure from its seeds
  • Tracing a column conversion mismatch
  • Investigating Parquet and native partition differences
  • Debugging column top or NULL mismatches

포함된 파일(1)

  • SKILL.md6.3 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Debug the fuzz test failure described by $ARGUMENTS.

Background

WAL fuzz tests (WalWriterFuzzTest, AbstractFuzzTest) are nearly deterministic with fixed seeds. The same seeds produce the same sequence of operations. Failures reproduce reliably once you have the seeds.

The test applies the same randomly-generated transactions three ways:

  1. Non-WAL table — direct writer, ground truth
  2. WAL sequential — single WAL writer
  3. WAL parallel ple concurrent WAL writers

TestUtils.assertSqlCursors() compares WAL tables against non-WAL. The assertion format is: Row N column COL[TYPE] expected:<X> but was:<Y>.

Step 1: Get the seeds

Find the random seeds in the test output:

random seeds: 137113830825708L, 1776424558803L

If the user provided a failure log, extract the seeds from there and compare them against the seeds currently hardcoded in the test method. If the test uses generateRandom(LOG) (no fixed seeds), note this — you'll need to hardcode the failing seeds to reproduce later.

If the seeds are already hardcoded in the test and match the failure log, no reproduction step is needed — proceed directly to tracing.

Step 3: Trace the column lifecycle

This is the most important step for conversion-related failures. For each column involved in the assertion failure, build a chronological timeline of:

  1. Column add — when the column was added, which partitions already existed. Partitions created before the column was added have a column top (the column starts at a row offset within that partition, not at row 0).

  2. Column delete / rename — removals and renames that affect the column index chain.

  3. Column type conversions (ALTER COLUMN TYPE) — each conversion creates a new column index via replacingIndex. Track the full chain of types (e.g., INT → STRING → DATE). Key file: ConvertOperatorImpl.java.

  4. Partition format conversions — CONVERT PARTITION TO PARQUET and TO NATIVE. A parquet partition freezes the column type at conversion time. If a type change happened after parquet conversion, the parquet partition stores the old type. The ConvertOperatorImpl pre-pass converts parquet partitions to native when needed (chained conversions, symbol targets).

  5. Partition truncations (DROP PARTITION) — partitions removed mid-sequence change what data exists when later operations run.

Use Grep to search the fuzz generator and operation classes for LOG statements that trace these operations:

core/src/test/java/io/questdb/test/cairo/fuzz/FuzzChangeColumnTypeOperation.java
core/src/test/java/io/questdb/test/cairo/fuzz/FuzzConvertPartitionToParquetOperation.java
core/src/test/java/io/questdb/test/cairo/fuzz/FuzzConvertPartitionToNativeOperation.java
core/src/test/java/io/questdb/test/cairo/fuzz/FuzzTransactionGenerator.java
core/src/main/java/io/questdb/griffin/ConvertOperatorImpl.java

Step 4: Cross-reference with the failure

Map the failing assertion back to the timeline:

  • Which partition holds the failing row (based on its timestamp)?
  • Was that partition in parquet format at any point?
  • What type did the column have when the partition was converted to/from parquet?
  • Does the column have a column top in that partition (was it added after the partition)?

Step 5: Add debug logging

Do NOT change fuzz counts, probabilities, or feature gates. Fuzz tests are extremely sensitive to any modification — even a tiny change alters the random sequence and produces completely different transactions, making the failure non-reproducible.

Instead, add temporary debug logging to dump table state after each transaction. Useful things to log after each WAL apply / transaction commit:

  • Row count per partition (native and parquet)
  • Column tops for the failing column (and its replacingIndex chain) across all partitions
  • Partition list with format (native/parquet) and timestamp ranges
  • Column metadata: type, index in metadata, replacingIndex chain
  • Partition format changes (log when a partition switches between native and parquet)

Add logging in AbstractFuzzTest.runFuzz() or in the WAL apply loop. For example, after each transaction is applied, iterate over partitions and dump the state of the columns involved in the failure.

Also useful:

node1.setProperty(PropertyKey.DEBUG_WAL_APPLY_BLOCK_FAILURE_NO_RETRY, true);

Step 6: Identify root cause

Common failure patterns:

SymptomLikely causeWhere to look
Data mismatch after parquet round-tripParquet decoder type mappingcore/rust/qdbr/src/parquet_read/decode.rs
Wrong value in converted columnPre-pass missed a parquet partitionConvertOperatorImpl.java pre-pass logic
Symbol column errors from parquetParquet not converted to native before symbol conversionConvertOperatorImpl.java isTargetSymbol check
NULL vs sentinel mismatchType conversion doesn't handle NULL for non-nullable typesConversion logic for BYTE/SHORT/BOOLEAN
Column top mismatchColumn top not propagated to new column indexcolumnVersionWriter.upsertColumnTop() in ConvertOperatorImpl

Key files

  • core/src/test/java/io/questdb/test/cairo/fuzz/WalWriterFuzzTest.java — test entry points
  • core/src/test/java/io/questdb/test/cairo/fuzz/AbstractFuzzTest.java — runFuzz(), comparison logic
  • core/src/test/java/io/questdb/test/cairo/fuzz/FuzzTransactionGenerator.java — operation generation
  • core/src/test/java/io/questdb/test/cairo/fuzz/FuzzChangeColumnTypeOperation.java — type change logic
  • core/src/main/java/io/questdb/griffin/ConvertOperatorImpl.java — column type conversion engine
  • core/src/main/java/io/questdb/cairo/TableWriter.java — partition format, column tops
  • core/rust/qdbr/src/parquet_read/decode.rs — parquet type decoding

Running

# Single method from repo root
mvn test --batch-mode \
  -Dtest.include="%regex[.*WalWriterFuzzTest.*]" \
  -Dtest="**/WalWriterFuzzTest.java#testConvertPartitionToParquet" \
  -DfailIfNoTests=false -Dsurefire.failIfNoSpecifiedTests=false \
  -pl questdb/core

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Posts the latest review report as an approval on the pull request for the checked-out branch, then adds the “QUEUED FOR MERGE” label. It first checks that the review meets the stated approval criteria.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Approving a reviewed pull request
  • Adding the merge queue label after approval
  • Posting a review report to its pull request
questdb/questdb1.7만2026년 10월 26일 업데이트

Investigate failing QuestDB WAL/O3 tests on the lazy geometry branch, focusing on composite partitions made of multiple pieces. Use seeds, logs, and partition invariants to trace the failure and build a deterministic reproducer when possible.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Tracing a failing WAL/O3 test
  • Replaying a failure with fixed random seeds
  • Building a deterministic partition reproducer
questdb/questdb1.7만2026년 10월 26일 업데이트

fix-ci

무료

Check a pull request’s CI status, summarize failed tests and build checks, and trace failures to the proposed changes. The skill can update test expectations when the cause and intended behavior are clear, and presents uncertain failures for discussion.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Summarizing failed checks on a pull request
  • Finding test names and failure messages
  • Updating an assertion after an intentional output change
questdb/questdb1.7만2026년 10월 26일 업데이트

fix-pr

무료

Investigate actionable QuestDB pull request findings, trace root causes and affected callers, and test a proposed fix against existing contracts. An independent reviewer checks the design before production edits and reviews the combined result before completion.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Investigating the cause behind a PR finding
  • Checking how a proposed fix affects callers and contracts
  • Planning and validating a regression-tested change
questdb/questdb1.7만2026년 10월 26일 업데이트

fix-pr

무료

Validate actionable findings from a QuestDB pull request review one at a time. Reproduce user-visible problems with regression tests where practical, make a focused and performant fix, run tests, and require an independent review before proceeding to the next finding.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Verify a pasted QuestDB review finding against the current code
  • Reproduce a reported bug with a regression test
  • Apply a focused fix and run relevant tests
questdb/questdb1.7만2026년 10월 26일 업데이트

fix-pr

무료

Validate actionable QuestDB pull request findings against the code, trace their causes, and fix confirmed issues with regression tests and independent review. It helps preserve legitimate behavior while checking the combined changes before completion.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Checking whether a pasted PR review finding is real
  • Reproducing a reported bug with a regression test
  • Applying a focused fix and reviewing its impact
questdb/questdb1.7만2026년 10월 26일 업데이트

questdb의 스킬 모두 보기

이 스킬의 문제 신고