mz-parallel-workload

Extends the parallel-workload framework to stress-test Materialize with concurrent random SQL actions.

6.4k|512|Updated Feb 22, 2019
One-click install
npx skills add https://github.com/MaterializeInc/materialize --skill mz-parallel-workload
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: mz-parallel-workload
Source: https://github.com/MaterializeInc/materialize/tree/main/.agents/skills/mz-parallel-workload
Command: npx skills add https://github.com/MaterializeInc/materialize --skill mz-parallel-workload

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Materialize bugs that only surface as panics or unexpected errors under concurrent DDL/DML load are hard to reproduce with ordinary tests. This Skill guides you through adding new randomized actions to the parallel-workload stress framework so those concurrency bugs get caught automatically.

Core Features & Use Cases

  • Add New Stress Actions: Define Action subclasses in action.py, register them in weighted action lists (read, fetch, write, dml_nontrans, ddl), and control expected failures via errors_to_ignore().
  • Concurrency-Safe Patterns: Provides proven patterns for picking, creating, and dropping shared database objects under locks, respecting object limits, and using seeded RNG for reproducible failures.
  • Scenario Gating: Use the applicable() hook to restrict actions to specific scenarios (rename, cancel, kill, backup-restore, 0dt-deploy) without breaking end-of-run coverage checks.
  • Use Case: A bug report shows Materialize panicking when ALTER TABLE runs concurrently with DROP VIEW. Add a new DDL action with the right weight and expected-error list, then run bin/mzcompose --find parallel-workload run default --seed=42 to reproduce and verify the fix.

Quick Start

Ask the AI to add a new action to the parallel workload framework that exercises your SQL feature under concurrent load.

Frequently Asked Questions about mz-parallel-workload

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new action to the parallel workload framework?▼

Subclass Action in action.py and implement run(), then register the class with a weight in the appropriate action list such as ddl_action_list or read_action_list. Override errors_to_ignore() if the action can produce expected concurrent errors.

How do I run the Materialize parallel workload test?▼

Run bin/mzcompose --find parallel-workload run default with optional flags like --complexity=ddl, --scenario=regression, --runtime=300, and --seed=42. The seed makes failures reproducible across runs.

What is the difference between parallel workload and mz-benchmark?▼

Parallel workload catches panics and unexpected query errors under concurrency, not performance regressions. It does not verify result correctness; use mz-benchmark for performance measurement instead.

Why does my parallel workload action fail with unexpected errors?▼

Concurrent operations can legitimately produce errors like objects being dropped mid-query. Extend errors_to_ignore() with the expected message, optionally conditioned on complexity or scenario, instead of adding more locking.

How do I make a parallel workload action run only in certain scenarios?▼

Override the applicable() method to check exe.db.scenario, for example returning True only for Scenario.Rename. Do not gate inside run(), because skipped actions would distort the end-of-run coverage check.

How do I reproduce a parallel workload failure?▼

Every action uses a seeded random.Random instance, so rerun with the same --seed value reported in the failure. Never call random.choice() directly, as that breaks reproducibility.