Skip to content

Commit e011bff

Browse files
subtleGradientsubtleGradient
committed
capture more tasks
1 parent a7ddaee commit e011bff

File tree

4 files changed

+233
-0
lines changed

4 files changed

+233
-0
lines changed

‎.tasks/triage/TASK-184-fix-resurrection-via-sentinel.md‎

Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
# TASK-184 — Fix resurrection via sentinel for tombstoned rows
2+
3+
## Goal
4+
Fix Zig implementation to resurrect tombstoned rows when receiving a sentinel with higher CL.
5+
6+
## Status
7+
- State: triage
8+
- Priority: HIGH (sync incompatibility)
9+
- Discovered: Round 62 (TASK-161 test suite)
10+
11+
## Problem
12+
When a tombstoned row (CL=2) receives a resurrection sentinel (CL=3), Zig does NOT resurrect the row. Rust/C correctly resurrects it.
13+
14+
**Test failure from `test-resurrection-parity.sh`:**
15+
```
16+
Test 2c: Row resurrected after sentinel merge
17+
FAIL: Resurrected row count - DIVERGENCE
18+
Zig: 0
19+
Rust/C: 1
20+
Expected: 1
21+
```
22+
23+
## Scenario
24+
1. Site A: INSERT row (CL=1) → DELETE row (CL=2) → INSERT row (CL=3) — resurrection
25+
2. Site B: INSERT row (CL=1) → DELETE row (CL=2) — tombstoned
26+
3. Site B receives resurrection sentinel (CL=3) from Site A
27+
4. **Expected**: Row resurrected, CL=3
28+
5. **Actual (Zig)**: Row stays tombstoned
29+
30+
## Root Cause (hypothesis)
31+
The sentinel merge path in `zig/src/merge_insert.zig` likely doesn't handle the case where:
32+
- Local row is tombstoned (has sentinel with lower CL)
33+
- Incoming sentinel has higher CL
34+
- Should trigger resurrection by clearing tombstone status
35+
36+
## Files to Modify
37+
- `zig/src/merge_insert.zig` — sentinel handling in merge path
38+
- Possibly `zig/src/changes_vtab.zig` — xUpdate path
39+
40+
## Acceptance Criteria
41+
1. `bash zig/harness/test-resurrection-parity.sh` — Test 2 passes
42+
2. All other resurrection tests still pass
43+
3. No regressions in `make -C zig test-parity`
44+
45+
## Parent Docs / Cross-links
46+
- Test: `zig/harness/test-resurrection-parity.sh` (Test 2: Dead via sentinel)
47+
- Triggering task: `.tasks/done/TASK-161-resurrection-parity-suite.md`
48+
- Python reference: `py/correctness/tests/test_cl_merging.py::test_resurrection_of_dead_thing_via_sentinel`
49+
50+
## Progress Log
51+
- 2025-12-22: Created from Round 62 divergence discovery.
52+
53+
## Completion Notes
54+
(Empty until done.)

‎.tasks/triage/TASK-185-fix-spurious-sentinel-on-merge.md‎

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
# TASK-185 — Fix spurious sentinel creation during merge
2+
3+
## Goal
4+
Fix Zig implementation to NOT create sentinel entries when syncing INSERT changes to a new site.
5+
6+
## Status
7+
- State: triage
8+
- Priority: HIGH (wire format divergence)
9+
- Discovered: Round 62 (TASK-166 test suite)
10+
11+
## Problem
12+
When syncing INSERT changes to a site that doesn't have the row, Zig incorrectly creates sentinel entries (`cid='-1'`) alongside the column changes. Rust/C correctly omits sentinels since no DELETE operation occurred.
13+
14+
**Test failure from `test-sentinel-parity.sh`:**
15+
```
16+
Test 4: No sentinel on merge - FAIL
17+
DIVERGENCE: Zig creates 3 spurious sentinels vs Rust 0
18+
19+
Rust/C Site B sentinels: 0
20+
Zig Site B sentinels: 3
21+
22+
When syncing INSERT changes to a new site, Zig incorrectly creates
23+
sentinel entries (cid='-1') for the new rows. The Rust/C oracle
24+
correctly omits sentinels since no DELETE occurred.
25+
```
26+
27+
## Scenario
28+
1. Site A: INSERT 3 rows
29+
2. Sync A→B via `INSERT INTO crsql_changes SELECT * FROM crsql_changes`
30+
3. **Expected**: Site B has data rows, NO sentinels in clock table
31+
4. **Actual (Zig)**: Site B has data rows AND 3 spurious sentinel entries
32+
33+
## Root Cause (hypothesis)
34+
The `changesUpdate` path in `zig/src/changes_vtab.zig` creates sentinels when inserting new rows during merge. It should only create sentinels when:
35+
1. A DELETE operation is being merged, OR
36+
2. Passing through an existing sentinel from source
37+
38+
## Files to Modify
39+
- `zig/src/changes_vtab.zig` — xUpdate handler for INSERT path
40+
- Possibly `zig/src/merge_insert.zig` — sentinel creation logic
41+
42+
## Acceptance Criteria
43+
1. `bash zig/harness/test-sentinel-parity.sh` — Test 4 passes
44+
2. All other sentinel tests still pass (especially Test 5: propagation)
45+
3. No regressions in `make -C zig test-parity`
46+
47+
## Parent Docs / Cross-links
48+
- Test: `zig/harness/test-sentinel-parity.sh` (Test 4: No sentinel on merge)
49+
- Triggering task: `.tasks/done/TASK-166-sentinel-parity-suite.md`
50+
- Python reference: `py/correctness/tests/test_sentinel_omission.py`
51+
52+
## Progress Log
53+
- 2025-12-22: Created from Round 62 divergence discovery.
54+
55+
## Completion Notes
56+
(Empty until done.)

‎.tasks/triage/TASK-186-schema-mismatch-unknown-column-behavior.md‎

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
# TASK-186 — Decide schema mismatch behavior for unknown columns
2+
3+
## Goal
4+
Decide whether Zig should error or ignore unknown columns during sync, then align implementations.
5+
6+
## Status
7+
- State: triage
8+
- Priority: MEDIUM (behavioral difference, not data corruption)
9+
- Discovered: Round 62 (TASK-173 test suite)
10+
11+
## Problem
12+
When source has a column that destination doesn't have, the implementations differ:
13+
- **Zig**: Returns ERROR
14+
- **Rust/C**: Gracefully IGNORES the unknown column, syncs known columns
15+
16+
**Test failure from `test-schema-mismatch.sh`:**
17+
```
18+
Divergences found:
19+
- source_has_extra_column: Zig='ERROR' vs Rust='IGNORED'
20+
```
21+
22+
## Scenario
23+
1. Site A: table with columns (id, name, extra)
24+
2. Site B: table with columns (id, name) — no 'extra' column
25+
3. Site A: INSERT with extra='value'
26+
4. Sync A→B
27+
5. **Rust/C**: Row synced, 'extra' column data ignored, known columns applied
28+
6. **Zig**: ERROR returned, nothing synced
29+
30+
## Analysis
31+
Both approaches have merit:
32+
- **Zig (strict)**: Catches schema drift early, prevents silent data loss
33+
- **Rust/C (lenient)**: Allows staggered migrations, more forgiving in production
34+
35+
## Decision Needed
36+
1. Should Zig match Rust/C behavior (ignore unknown columns)?
37+
2. Or is the strict behavior intentional/preferred?
38+
3. Should this be configurable?
39+
40+
## Files to Modify
41+
- `zig/src/changes_vtab.zig` — column lookup in xUpdate
42+
- `zig/src/merge_insert.zig` — column resolution
43+
44+
## Acceptance Criteria
45+
1. Decision documented
46+
2. If aligning with Rust/C: `bash zig/harness/test-schema-mismatch.sh` — Test 1 passes
47+
3. If keeping strict: Test marked as known divergence with rationale
48+
49+
## Parent Docs / Cross-links
50+
- Test: `zig/harness/test-schema-mismatch.sh` (Test 1: source_has_extra_column)
51+
- Triggering task: `.tasks/done/TASK-173-schema-mismatch.md`
52+
53+
## Progress Log
54+
- 2025-12-22: Created from Round 62 divergence discovery.
55+
56+
## Completion Notes
57+
(Empty until done.)

‎.tasks/triage/TASK-187-fix-star-topology-convergence.md‎

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
# TASK-187 — Fix star topology sync convergence failure
2+
3+
## Goal
4+
Fix Zig implementation to correctly converge in hub-and-spoke (star) topology sync patterns.
5+
6+
## Status
7+
- State: triage
8+
- Priority: HIGH (multi-node sync broken)
9+
- Discovered: Round 62 (TASK-179 test suite)
10+
11+
## Problem
12+
In a hub-and-spoke topology where all nodes sync only through a central hub, Zig nodes fail to converge to the same state. Rust/C converges correctly.
13+
14+
**Test failure from `test-multinode-sync.sh`:**
15+
```
16+
Test 3: Star topology - FAIL
17+
18+
Hub data: 1|updated_by_b|c2|c3|c4
19+
3|d1|d2|d3|d4
20+
B data: 1|updated_by_b|c2|c3|c4
21+
3|d1|d2|d3|d4
22+
C data: 1|c1|c2|c3|c4 <-- wrong! didn't get B's update
23+
3|d1|d2|d3|d4
24+
D data: 2|d1|d2|d3|d4 <-- completely wrong rows
25+
3|updated_by_b|b2|b3|b4
26+
27+
FAIL: Hub and C diverged
28+
FAIL: Hub and D diverged
29+
```
30+
31+
## Scenario
32+
1. Create 4 databases: Hub, B, C, D
33+
2. B, C, D each create unique rows
34+
3. All sync to Hub (Hub has all rows)
35+
4. Hub syncs back to all spokes (all should have same data)
36+
5. B updates row 1, C deletes row 2
37+
6. Sync through Hub again
38+
7. **Expected**: All 4 nodes converge to same state
39+
8. **Actual (Zig)**: C didn't get B's update, D has completely wrong data
40+
41+
## Root Cause (hypothesis)
42+
Likely issues:
43+
1. Site ID filtering not correctly applied when relaying changes through hub
44+
2. Version vector not properly tracking which changes came from which site
45+
3. Possible confusion between local vs remote site_id in change application
46+
47+
## Files to Modify
48+
- `zig/src/changes_vtab.zig` — site_id filtering in xFilter/xUpdate
49+
- `zig/src/merge_insert.zig` — change application with site_id tracking
50+
- Possibly `zig/src/site_identity.zig` — site ordinal handling
51+
52+
## Acceptance Criteria
53+
1. `bash zig/harness/test-multinode-sync.sh` — Test 3 (star topology) passes
54+
2. All other multinode tests still pass
55+
3. No regressions in `make -C zig test-parity`
56+
57+
## Parent Docs / Cross-links
58+
- Test: `zig/harness/test-multinode-sync.sh` (Test 3: Star topology)
59+
- Triggering task: `.tasks/done/TASK-179-multinode-sync.md`
60+
- Python reference: `py/correctness/tests/test_cl_merging.py`
61+
62+
## Progress Log
63+
- 2025-12-22: Created from Round 62 divergence discovery.
64+
65+
## Completion Notes
66+
(Empty until done.)

0 commit comments

Comments
 (0)