// Trigger: "commit", "prepare commit", "create PR", "push", "open pull request", or mentions committing, pre-commit checks, pull requests in Materialize. Also "ship it", "ready to merge". For code review use mz-pr-review.
| name | mz-commit |
| description | Trigger: "commit", "prepare commit", "create PR", "push", "open pull request", or mentions committing, pre-commit checks, pull requests in Materialize. Also "ship it", "ready to merge". For code review use mz-pr-review. |
Read doc/developer/guide-changes.md for the full conventions on submitting and reviewing changes.
Before committing, run these and fix any warnings:
bin/fmt (formats .rs, .py, and .proto files)bin/lint (can error if tools are missing; use bin/ci-builder run stable bin/lint as an alternative)cargo clippy --all-targets -- -D warningsDo not manually update *.snap files.
Use cargo test followed by cargo insta accept to update snapshot files.
Rewrite datadriven test expectations with REWRITE=1 cargo test ....
Materialize uses squash merging, so the PR title becomes the commit subject on main.
adapter: , storage: , compute: , sql: .Write a thorough PR description explaining the rationale for the change.
Mention which tests were added or modified in the pull request description, but do not list which tests were run.
To auto-close issues, include Fixes database-issues#NNNN.
Add release notes for user-visible changes (should complete "This release will...").
Never regenerate the entire Cargo.lock — bare cargo update bumps every semver-compatible dep and introduces unrelated breakage (e.g., os_info pulling in objc2 on macOS, chrono-tz changing timezone data, serde_path_to_error changing error formats).
cargo check. It updates only what's needed.cargo update -p <crate> (add --precise <ver> to pin).git diff Cargo.lock | grep '^[+-]version' | head -40
cargo update -p <crate> --precise <old-version>.cargo check (not cargo update). This preserves existing pins while adding only what the new commits require.main branch of MaterializeInc/materialize.main on MaterializeInc/materialize.Cut a dbt-materialize PyPI release: bump the version in `__version__.py` and `setup.py`, date the `Unreleased` CHANGELOG entry, and open the release PR with a `Ship: <url>` body. Trigger: "cut a dbt release", "release dbt-materialize", "release the dbt adapter", "ship dbt-materialize vX.Y.Z", "publish dbt-materialize to PyPI", "bump dbt-materialize version", "new dbt adapter version". Use this skill even if the user just says "ship the dbt adapter" or pastes a feature PR and asks for "the next dbt release" without naming version mechanics.
Correctness invariants + architecture: adapter, coordinator, pgwire, peek paths, timestamp oracle. Trigger: questions about these subsystems — "how does coordinator work", "what are read holds", "explain peek path", "how does timestamp selection work", "why does this query block". Also edits in src/adapter/, src/pgwire/, src/timestamp-oracle/.
Add/modify/debug Materialize perf benchmark scenarios. Three frameworks: Feature Benchmark (single-op micro), Scalability Test (SQL throughput under concurrency), Parallel Benchmark (sustained latency via scenarios.py). Trigger: "benchmark", "feature benchmark", "scalability test", "parallel benchmark", "performance regression", "micro-benchmark", "TPS", "latency test", or edits in feature_benchmark/scenarios/, scalability/workload/workloads/, parallel_benchmark/scenarios.py. Note: measurement, not panic-stress (see mz-parallel-workload).
Investigate CI failures on PR via gh + bk CLI. Trigger: failing checks, Buildkite failures, CI issues — "why is CI red", "build broken", "checks failing", "what went wrong in CI", "nightly broke", "tests failing on this PR", or pasted Buildkite URL. Also PR number + why failing.
Add/modify/debug limits test. Trigger: "limits test", "Generator subclass", "many objects", "scaling test", or stress-test Materialize with many objects (tables, views, sources, indexes). Also edits in test/limits/mzcompose.py.
Extend parallel-workload stress framework: random SQL concurrently to catch panics + unexpected errors (not perf — see mz-benchmark). Trigger: "parallel workload", "parallel-workload", "action.py" re parallel workload, or testing panics/unexpected errors under concurrency. Also "add this to parallel workload" or bug that panics under concurrent DDL/DML.