Record the human treatment of a parked STA event
Writes the audit record that answers the three-day dead-letter window: which parked record, from which direction, under which parking token, and what the operator did about it (replayed, recorded, escalated). It does NOT remove anything: the dead-letter destination is the Kafka topic lerian.streaming.br-sisbajud.dlq, a LOG with its own retention, so a treated record stays exactly where it is and this acknowledgement — not the record’s absence — is what says it was handled. Replaying means seeking the consumer group back to the source offset the record’s headers name. Answers with a receipt id for the ticket. 422 when the parking token is not one the consumer emits, when the action is unknown, or when institutionId or eventId are missing — the refusal carries a code and a canned detail, so the valid tokens are published as this request’s reason enum rather than named in the answer.
Authorizations
JWT bearer token issued by the identity provider.
Path Parameters
Lerian STA's event id, exactly as it appears on the parked message. It is a string on Lerian STA's side and is not required to be a UUID.
"evt-7f3c9a10"
Body
What you did: replayed (cause fixed, message shovelled back — the consumer is idempotent), recorded (the disposition stands; the commonest case is parse_rejected, where the remittance row is already REJECTED), escalated (the order could not be reproduced inside the window and the institution is talking to the court).
replayed, recorded, escalated "replayed"
The institution on whose behalf the dead-letter queue was drained. This is NOT necessarily the institution the message resolved to: institution_unresolved is itself one of the parking reasons, and a message parked under it resolved to nobody. In multi-tenant mode it is the tenant whose vhost the queue lives in.
"44444444-4444-4444-4444-444444444444"
Which of the two queues the message was parked from. These are the values the metric's queue label carries — the direction, not the configured queue name, so the record can be read next to the series.
inbound, outbound "outbound"
The parking token, read from the message's x-sisbajud-reason header. The values are the consumer's closed set; "other" is deliberately absent, being the fallback the code produces for a token nobody declared.
direction_mismatch, doctype_header_mismatch, doctype_not_allowed, doctype_pair_mismatch, doctype_unexpected_shape, doctype_unmapped, event_duplicate, handler_not_wired, handler_panic, institution_unresolved, lock_held, object_key_out_of_scope, object_missing, parse_rejected, payload_shape_invalid, payload_too_large, receive_transient, sha256_mismatch, sta_state_unknown, tenant_scope_mismatch, tenant_set_unavailable, terminal_conflict, transfer_not_found, transition_out_of_order "institution_unresolved"
Why, in your own words. MUST NOT contain personal data (CPF/CNPJ, names, process numbers) or monetary values: it is written verbatim into a permanent, append-only audit record. Text carrying a run of more than 10 digits is refused with 422 — that is a floor against pasting an identifier, not a check that recognises a name.
"institution config was missing the STA credential; added and replayed"
Response
OK
The audit record's id. It identifies THIS acknowledgement, not the message: Lerian STA's event id is a string and is recorded as the audit correlation id.
"cccccccc-cccc-cccc-cccc-cccccccccccc"