The quote's external id, or null when the barcode resolved to no quote.
A single row by its own id. Null when no row exists at that id.
External ids of quotes carrying an unprocessed row older than the cutoff.
The Phase 2 sweep's backstop for a handler that recorded a row and then
failed to start (or signal) the apply workflow. Backed by the partial
index greendot_consumption_event_unprocessed_received_at_idx.
The inbox rows matching every criterion given, in the order the register produced them.
That order is the partner's own clock (request_date_time, Green Dot's
RequestHeader.RequestDateTime), not ours. received_at is
DEFAULT now(), the transaction timestamp: two inserts can collide on it,
and a slow Auth insert can commit after a later Void while still carrying
the earlier value, so it alone does not reflect what happened at the
register. received_at breaks ties on a shared request_date_time, id
breaks any tie still left, so the sort is total. The per-quote drain
applies strictly in this order.
Unpaginated on purpose: every caller wants the whole matched set, and a
quote's inbox holds one row per call the register made against one
barcode. A pageSize here would let the drain silently skip a row it is
required to apply.
Optionalapplied?: booleanRows whose side effects ran (true) or did not (false).
Optionalids?: number[]Optionalphases?: ("AUTH" | "AUTH_COMMIT" | "AUTH_VOID")[]Optionalprocessed?: booleanClosed rows (true) or ones still waiting to be applied (false).
OptionalquoteIds?: string[]OptionalrequestIds?: string[]The CASH barcodes created within the lookback since Green Dot's last Auth on any barcode, the customers who made them, and the first one's age. A register scan sends an Auth, so a pile with none means no scan reached us.
The sweep's own backlog, past the same cutoff it nudges on: how many unprocessed rows, across how many quotes, and how old the oldest one is. A row this old is one the sweep has already re-nudged and nothing closed. The sweep logs this every run, zeroes included, so the metric filter reading that line has a zero to clear an alarm against.
Closes the row with the code the handler answered. processed_at IS NULL
in the WHERE makes this an atomic claim, not a plain write: only the
first caller to reach it for a given row updates anything, so the
returned boolean says whether THIS call was the one that closed the row,
as opposed to a concurrent caller having already closed it. A second
applied: true AUTH_COMMIT on one quote violates the partial unique
index and throws; nothing here catches it.
The inbox for Green Dot Consumption API calls: one row per Auth, AuthCommit or AuthVoid, written before the phase's side effects run. A delivery that repeats a
(phase, RequestID)gets the row already there, and the storedresponseCodeis what the handler replays.