Skip to content

Commit 9eaeeae

Browse files
docs: add triage tasks for cross-open interop + fail-fast harness policy
TASK-143: Cross-open modification compatibility gap TASK-144: Cross-platform compat no-skip TASK-145: Schema evolution no acceptable errors TASK-146: Fail fast and loud harness policy TASK-147: Cross-open modification interoperability (hard requirement) Updated gap backlog to reflect remaining compatibility gaps.
1 parent 431b062 commit 9eaeeae

File tree

2 files changed

+138
-0
lines changed

2 files changed

+138
-0
lines changed
Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
# TASK-146 — Fail fast and loud across all harnesses (no SKIP / no KNOWN_FAIL / no "acceptable" errors)
2+
3+
## Goal
4+
Make every harness/test runner fail fast and loud if any assumption, dependency, expectation, or invariant is unmet or invalid.
5+
6+
This turns the harness suite into an *invalidation engine*, not a best-effort report generator.
7+
8+
## Status
9+
- State: triage
10+
- Priority: high
11+
12+
## Context
13+
We discovered multiple places where gaps or missing dependencies can be silently ignored:
14+
15+
1. Cross-open modification compatibility is currently treated as "known limitation" instead of a failing test:
16+
- `zig/harness/test-cross-open-parity.sh` reports `KNOWN_FAIL: 3` (XO-003 / XO-004 / XO-006)
17+
- These represent real compatibility gaps.
18+
19+
2. Some harnesses SKIP entirely when dependencies are missing:
20+
- `zig/harness/test-cross-platform-compat.sh` can print `SKIP: Rust/C extension not found ...` and exit successfully.
21+
22+
3. Some harnesses treat SQL errors as PASS:
23+
- `zig/harness/test-schema-evolution.sh` currently logs warnings like `WARN: SQL error (may be expected behavior)` and marks PASS.
24+
25+
The desired posture is:
26+
- Missing dependency → FAIL with actionable instructions.
27+
- Known limitation / known fail → FAIL (tracked by task card; not ignored).
28+
- Error-is-acceptable → replace with explicit expected-reject assertion + post-error invariants.
29+
30+
## Files to Modify
31+
(Exact scope to confirm during execution; keep tight.)
32+
- `zig/harness/test-parity.sh` (top-level aggregator: enforce nonzero exit on skipped subtests)
33+
- `zig/harness/test-cross-open-parity.sh` (remove `KNOWN_FAIL` pathway; make XO gaps real FAIL)
34+
- `zig/harness/test-cross-platform-compat.sh` (remove silent SKIP; fail with provisioning steps)
35+
- `zig/harness/test-schema-evolution.sh` (replace "acceptable error" PASS with explicit assertions)
36+
- Any `zig/harness/test-*.sh` that currently prints `SKIP:` / `SKIPPED:` / `WARN:` and still exits 0
37+
38+
## Acceptance Criteria
39+
1. Harness discipline
40+
- No harness script exits 0 when it printed any of:
41+
- `SKIP:` / `SKIPPED:`
42+
- `KNOWN_FAIL:` / `KNOWN LIMITATION:`
43+
- `WARN:` / "acceptable" errors
44+
- Instead, it exits nonzero with a clear, actionable message.
45+
46+
2. Dependency discipline
47+
- If a harness requires an oracle extension, sqlite version feature (DROP COLUMN), or other capability:
48+
- It either provisions it automatically in a deterministic way, OR
49+
- It fails with a single canonical instruction (e.g. `./scripts/update-crsqlite-oracle.sh`).
50+
51+
3. Invariant discipline
52+
- Any path that expects a failure (e.g. schema evolution conflicts) asserts:
53+
- the error class/message pattern
54+
- post-error invariants (no partial apply, expected db_version behavior, schema sanity, clock/changes sanity)
55+
56+
4. Aggregator discipline
57+
- `make -C zig test-parity` (or whichever CI entrypoint is canonical) fails if any sub-suite fails or is skipped.
58+
59+
## Parent Docs / Cross-links
60+
- `AGENTS.md` (Zig testing policy; no sqlite-cr for Zig)
61+
- `.tasks/triage/TASK-143-cross-open-modification-compat.md`
62+
- `.tasks/triage/TASK-144-cross-platform-compat-no-skip.md`
63+
- `.tasks/triage/TASK-145-schema-evolution-no-acceptable-errors.md`
64+
- `research/zig-cr/92-gap-backlog.md`
65+
66+
## Progress Log
67+
- 2025-12-21: Created from "zero failures" requirement; codifies fail-fast harness policy.
68+
69+
## Completion Notes
70+
(Empty until done.)
Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
# TASK-147 — Implement cross-open modification interoperability (Zig matches Rust/C trigger schema)
2+
3+
## Goal
4+
Change the Zig implementation to match the Rust/C implementation such that a database created by one implementation can be modified by the other and vice-versa.
5+
6+
This is a hard requirement.
7+
8+
## Status
9+
- State: triage
10+
- Priority: highest
11+
12+
## Problem Statement
13+
Cross-open read-only works, but cross-open modification fails due to trigger schema incompatibility.
14+
15+
Today:
16+
- Zig-created CRR triggers embed `crsql_pack_columns()` directly in trigger SQL.
17+
- Rust/C-created CRR triggers call helper functions `crsql_after_insert/update/delete()`.
18+
19+
When the other implementation opens the DB and performs INSERT/UPDATE/DELETE, triggers fire and fail:
20+
- Rust/C on Zig DB: error like `unsafe use of crsql_pack_columns`
21+
- Zig on Rust/C DB: error like `no such function: crsql_after_*`
22+
23+
This breaks the interoperability requirement.
24+
25+
## Proposed Direction (implementation sketch)
26+
Unify on the Rust/C trigger schema and semantics:
27+
28+
1. Add Zig implementations for the Rust/C trigger helper SQL functions:
29+
- `crsql_after_insert(table_name, pk_new...)`
30+
- `crsql_after_update(table_name, pk_new..., pk_old..., [non_pk_new..., non_pk_old...])`
31+
- `crsql_after_delete(table_name, pk_old...)`
32+
33+
2. Update Zig trigger generation to emit triggers that call these helpers (matching `core/rs/core/src/triggers.rs`), instead of embedding `crsql_pack_columns()` in SQL.
34+
35+
3. Ensure Zig can also operate correctly when opening an existing Rust/C-created DB that already has Rust-style triggers.
36+
37+
## Files to Modify
38+
(Keep tight; finalize during execution.)
39+
- `zig/src/as_crr.zig` (trigger SQL generation)
40+
- `zig/src/ffi/init.zig` (register new SQL functions)
41+
- New or existing Zig implementation files to host the helpers (e.g. `zig/src/local_writes/*.zig` or similar)
42+
- `zig/harness/test-cross-open-parity.sh` (convert known-fail paths into real assertions)
43+
44+
## Acceptance Criteria
45+
1. `bash zig/harness/test-cross-open-parity.sh`:
46+
- XO-003 PASS
47+
- XO-004 PASS
48+
- XO-006 PASS
49+
- `KNOWN_FAIL: 0`
50+
- `FAILED: 0`
51+
- `SKIPPED: 0`
52+
2. Cross-open modification performs real writes and correct metadata changes:
53+
- base table reflects modifications
54+
- `crsql_db_version()` advances appropriately
55+
- `__crsql_clock` / `crsql_changes` reflect those writes
56+
3. No harness uses sqlite-cr to test Zig extension behavior (must follow `AGENTS.md`).
57+
58+
## Parent Docs / Cross-links
59+
- `.tasks/triage/TASK-143-cross-open-modification-compat.md` (original gap capture)
60+
- `zig/harness/test-cross-open-parity.sh`
61+
- `core/rs/core/src/triggers.rs` (Rust trigger schema)
62+
- `core/rs/core/src/local_writes/after_{insert,update,delete}.rs` (semantics)
63+
64+
## Progress Log
65+
- 2025-12-21: Task created from hard requirement: cross-open modification must work both directions.
66+
67+
## Completion Notes
68+
(Empty until done.)

0 commit comments

Comments
 (0)