Discard an un-appliable TRUNCATE instead of looping the apply worker

[danolivo]

Problem

In DISCARD exception mode, handle_truncate() had no per-action exception handling. On the retry (use_try_block) pass it re-ran the truncate directly, so any failure — most commonly a relation that does not exist on the subscriber — escaped as an ERROR.

With use_try_block set and xact_had_exception still clear, apply_work()'s outer handler re-throws to exit the worker; the background worker then restarts, replays from the same position, and fails identically. The result is an apply-worker crash/restart loop that stalls every later change from that origin — spock.sync_event() included — so the whole transaction (its row changes too) never lands and the stream wedges.

The row handlers (handle_insert/update/delete) and the queued-SQL handler (handle_sql_or_exception()) already wrap their work in a subtransaction for exactly this reason. TRUNCATE was the one directly-applied operation missing it: ExecuteTruncateGuts() is called directly (not via ProcessUtility), and on a missing relation handle_truncate() simply ereported, with no savepoint to roll back to.

Fix

1. Extract apply_truncate() — a preparatory refactor with no behaviour change, isolating the relation resolution (including partition expansion) and the ExecuteTruncateGuts() call, i.e. the part of the path that can throw.

2. Discard the failing TRUNCATE in DISCARD mode — on the retry path, run apply_truncate() inside an internal subtransaction. On failure, roll back the savepoint, set xact_had_exception, log the discarded TRUNCATE to spock.exception_log, and carry on. This mirrors the pattern already used by the row and SQL handlers.

   TRANSDISCARD and SUB_DISABLE keep their unconditional skip: the whole transaction is being abandoned, so the truncate must not be attempted at all.

Behaviour

A TRUNCATE that cannot be applied on the subscriber is now discarded individually — recorded in spock.exception_log with operation = 'TRUNCATE' — while the other changes in the same transaction still apply and the apply worker keeps running. No more crash/restart loop on a missing relation.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 2 duplication

Metric	Results
Duplication	2

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 81f05394-e34d-4266-8837-e80b903c73fc

📥 Commits

Reviewing files that changed from the base of the PR and between fb3fb44 and 800dbce.

📒 Files selected for processing (3)

• src/spock_apply.c
• tests/tap/schedule
• tests/tap/t/031_discard_truncate_missing_relation.pl

---

📝 Walkthrough

Walkthrough

handle_truncate in spock_apply.c is refactored: truncation internals are extracted into a new apply_truncate static helper, and handle_truncate becomes a dispatcher that runs TRUNCATE inside a subtransaction under DISCARD mode (logging failures) or skips/logs under TRANSDISCARD/SUB_DISABLE. A new TAP test validates this behavior.

DISCARD TRUNCATE Handling and Test Coverage

Layer / File(s)	Summary
apply_truncate helper extraction src/spock_apply.c	Adds apply_truncate(remote_relids, restart_seqs) static function declaration and moves all truncation internals—relation OID resolution, exclusive locks, partition expansion, logical-decoding tracking, ExecuteTruncateGuts, and relation closing—from the old handle_truncate body into the new helper.
handle_truncate DISCARD subtransaction wrapper src/spock_apply.c	Rewrites handle_truncate as a thin dispatcher: reads the TRUNCATE payload, then routes to skip-and-log (TRANSDISCARD/SUB_DISABLE with use_try_block), a subtransaction with error logging on failure (DISCARD with use_try_block), or a direct apply_truncate call (no try block).
TAP test: DISCARD TRUNCATE with missing relation tests/tap/schedule, tests/tap/t/031_discard_truncate_missing_relation.pl	Schedules and implements a 2-node TAP test: sets up DISCARD exception logging, drops t_trunc only on the subscriber, runs a mixed provider transaction (INSERT/UPDATE/DELETE + TRUNCATE), asserts the TRUNCATE appears in spock.exception_log, confirms the DML effects replicate, verifies the subscription remains in replicating state, and checks replication continues after the discard.

🐇 A truncate came bouncing down the wire,
But the table was gone — oh, what a dire!
Into the exception log it hopped with grace,
While INSERT and DELETE kept up their pace.
The worker stayed calm, still replicating true —
One missing relation? No crash ensued! 🌿

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: DISCARD-mode TRUNCATE failures are discarded instead of looping the apply worker.
Description check	✅ Passed	The description directly matches the implemented refactor, DISCARD handling fix, and regression test.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch spoc-590

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}