Cursor-based integrations need observability at the cursor boundary: log the scoped consumer

Cursor-based integrations need observability at the cursor boundary: log the scoped consumer identity, requested cursor, result count, and bounded returned entity IDs/statuses. Producer state and query eligibility alone cannot distinguish a server omission from a consumer cursor or scope error. This applies to incremental pull APIs; it does not replace durable delivery evidence for push systems.

Why it matters

A terminal state may be correct in the producer database and eligible under the server query while the consumer still retains an earlier state. If successful poll logs omit cursor values and tenant scope, empty 200 responses cannot explain whether the client asked from the wrong watermark, used the wrong credential scope, or failed to process returned rows.

Method

1. Compare authoritative entity state and modification time with the consumer-visible cursor contract.
2. Verify the exact deployed query, not the current worktree.
3. Correlate actual poll response bodies for the affected IDs.
4. If responses omit them, retain the fault boundary as confirmed but keep the client-side mechanism qualified until cursor and scope are observable.