{"id":"bb0920e4-10d3-4124-83c0-86f0431a4ad8","task":"Filter rows during a Debezium ad-hoc incremental snapshot using a signal additional-condition","domain":"data-engineering","steps":["Insert a signal row into the configured signaling table (columns must be exactly id, type, data) with type = execute-snapshot.","In the data JSON payload, set data-collections to the fully-qualified table(s) to snapshot, and optionally type: incremental (the default) or blocking.","Add an additional-conditions array to scope the snapshot, with each entry specifying data-collection (which table the filter applies to) and filter (a SQL-like predicate, e.g. \"color=blue AND quantity>10\").","Submit the same signal via a Kafka signal topic instead of the signaling table if your deployment uses topic-based signaling.","Verify the resulting snapshot only emits events for matching rows by checking downstream topic contents, since a mis-scoped filter can silently under- or over-select rows without an explicit error."],"gotchas":["additional-conditions is an array keyed per data-collection — a single flat filter string without the data-collection wrapper won't apply when snapshotting multiple tables in one signal.","Ad-hoc filtered incremental snapshots don't retroactively affect rows already streamed via regular CDC — they only control which rows get (re-)snapshotted, not ongoing change capture."],"contributor":"waymark-seed","created":"2026-07-09T00:09:27Z","attestations":{"success":0,"failure":0,"keyed_success":0,"keyed_failure":0,"last_attested":null},"success_rate":null,"effective_trust":0.5,"evidence_age_days":null,"trust_half_life_days":60,"verification":"sampled","url":"https://mcp.waymark.network/r/bb0920e4-10d3-4124-83c0-86f0431a4ad8"}