CompleteGapHealCursor infers delivery IDs as int4 and fails above MaxInt32

[ewhauser]

Summary

In v0.4.2, delivery-gap healing can fail while completing a scan when GitHub returns a delivery ID larger than int32. The cursor columns are bigint, but CompleteGapHealCursor causes PostgreSQL/sqlc to infer observed_boundary_delivery_id as int4.

Observed behavior

For a delivery ID such as 3835152601846906886, the River job repeatedly fails with:

complete delivery-gap cursor: failed to encode args[1]: unable to encode 3835152601846906886 into binary format for int4 (OID 23): 3835152601846906886 is greater than maximum value for int4

The schema correctly defines both boundary_delivery_id and pass_boundary_delivery_id as bigint. Other gap-cursor queries generate an int64 parameter, but the generated CompleteGapHealCursorParams.ObservedBoundaryDeliveryID is interface{}.

The relevant expression is:

NULLIF(sqlc.arg(observed_boundary_delivery_id), 0)

The untyped zero causes the parameter to be inferred as int4 before it is coalesced into the bigint column.

Impact

• The active gap cursor remains incomplete.
• Periodic and retry jobs repeatedly encounter the same encoding failure.
• A job may later become a no-op because another lease is active, so a completed River state does not prove that the gap window completed.
• Webhook delivery-gap detection and redelivery are not reliably advancing.

Suggested fix

Give the argument an explicit bigint type, for example:

NULLIF(sqlc.arg(observed_boundary_delivery_id)::bigint, 0::bigint)

Then regenerate sqlc output.

Acceptance criteria

• CompleteGapHealCursorParams.ObservedBoundaryDeliveryID is generated as int64.
• A database test completes a gap cursor using a delivery ID greater than math.MaxInt32.
• The test verifies that the boundary advances, the pass boundary is cleared, and the cursor is marked completed.
• The completion path no longer produces an OID 23/int4 encoding error.