fix: guard FK counter reconciliation with REPLACE conflict check

[reverb256]

Summary

Fixes #6218 — deferred FK violation counter double-decremented during UPDATE on parent table.

The issue: emit_fk_parent_new_key_reconcile was called unconditionally for all UPDATE operations on parent tables with deferred FK children. emit_fk_update_parent_actions already handles the correct increment (OLD key) and decrement (NEW key) cycle. The unconditional second call produces a duplicate decrement loop in the bytecode, causing the FK counter to drift to zero and allowing COMMIT to succeed when it should fail.

The fix: guard the call with matches!(effective_rowid_alias_conflict, ResolveType::Replace) so it only runs during REPLACE conflict resolution, which is what the function's own documentation says it should do.

Before fix

PRAGMA foreign_keys = ON;
CREATE TABLE p (id INTEGER PRIMARY KEY);
CREATE TABLE c (id INTEGER PRIMARY KEY, pid INT REFERENCES p(id) DEFERRABLE INITIALLY DEFERRED);
INSERT INTO p VALUES (24);
INSERT INTO c VALUES (1, 24);
INSERT INTO c VALUES (2, 24);
BEGIN;
SAVEPOINT sp0;
UPDATE p SET id = 4 WHERE id = 24;
RELEASE sp0;  -- Turso: succeeds (BUG, counter is 0)
COMMIT;       -- Turso: succeeds (BUG, orphans c rows)

After fix

RELEASE sp0;  -- succeeds (deferred, correct)
COMMIT;       -- Error: deferred foreign key constraint failed (correct, matches SQLite)

Tests

Two new sqltest regression tests in testing/sqltests/tests/savepoint.sqltest:

• deferred-fk-update-parent-pk-in-savepoint-rejects-commit — verifies COMMIT fails
• deferred-fk-update-parent-pk-rollback-restores-state — verifies ROLLBACK TO restores state

All 23 savepoint tests pass.

Description of AI Usage

Used AI assistance for code exploration and understanding the bytecode generation pipeline. The fix itself is a one-line guard, as identified in the issue by @LeMikaelF.

[turso-bot]

Please review @pereman2

[github-actions]

Fossier: PR Auto-Closed

This PR was automatically closed because @reverb256 did not meet the trust threshold for this repository.

Score Breakdown

Total Score: 36.2/100 | Confidence: 100% | Outcome: DENY

Signal	Value	Score	Weight
account_age	1105	1.00	0.07
public_repos	14	0.70	0.04
contribution_history	14	0.07	0.04
follower_ratio	0.67	0.33	0.04
bot_signals	False	0.50	0.03
open_prs_elsewhere	10	0.00	0.07
closed_prs_elsewhere	9	0.10	0.08
merged_prs_elsewhere	11	1.00	0.06
prior_interaction	0	0.00	0.24
activity_velocity	3	0.50	0.06
pr_content	...	1.00	0.06
commit_email	no_email	0.50	0.03
pr_description	...	0.55	0.04
repo_stars	18181	0.30	0.03
org_membership	0	0.20	0.02
commit_verification	...	0.30	0.03
contributor_stars	0	0.00	0.03

Appeal

If you believe this is a mistake, please open an issue to request manual review. A maintainer can vouch for you by adding your username to the VOUCHED.td file.

You can also reach the maintainers at: https://discord.gg/mNUkCHs2R to appeal this decision

[PThorpe92]

/fossier approve

[turso-bot]

Please review @pereman2

[reverb256]

Fix for CI failures

The two failing tests ( and ) use UNIQUE ON CONFLICT REPLACE rather than INTEGER PRIMARY KEY, so the rowid alias conflict clause is Abort (not Replace).

My previous guard matches!(effective_rowid_alias_conflict, ResolveType::Replace) only caught the PRIMARY KEY REPLACE case. The UNIQUE index REPLACE case was missed.

Root cause: When Phase 1 REPLACE deletes a parent row, emit_fk_delete_parent_existence_check_single increments the deferred FK counter. The BEFORE-check's NEW pass then tries to decrement but FkIfZero guards it (counter was 0 at that point). So the counter ends up at +1. The reconciliation is supposed to bring it back to 0, but our guard prevented it from running.

Fix: Check both the rowid alias conflict AND whether any unique index in the update has ON CONFLICT REPLACE:

let has_replace_conflict = matches!(effective_rowid_alias_conflict, ResolveType::Replace)
    || indexes_to_update.iter().any(|idx| idx.on_conflict == Some(ResolveType::Replace));

This correctly covers both REPLACE sources.