Abandon one unreadable record on a DICT poll feed
Permanently gives up on ONE record BACEN serves that this deployment cannot read or store, so the feed can move past it. A DICT poll feed holds its position on such a record rather than passing it by silently, which is correct and has no other ending: clearing the feed’s blocked marker resumes the walk at the same position and it stops again on the same record. This route is the human decision that ends that loop, and it is deliberately not the unblock route with a flag — unblocking says try again, this says give up on this one. It is refused for a caller with no identifiable principal, requires a reason, and writes an audit row naming who, which record and why. The record then stays listed on GET /api/v1/dict/discovery-feeds forever: an abandonment that ages out of a log is exactly the silent loss this verb exists to avoid. Only the named record is passed; every other held record still holds the feed. Idempotent — re-sending the same record is a no-op that is still audited. The write-off list is bounded per feed and is never trimmed to make room: at the limit this route refuses with 409 and says so plainly, because that many records given up on one feed is a systemic refusal rather than that many accidents. GET /api/v1/dict/discovery-feeds reports abandonedRecordsRemaining on every feed, and the brspi_dict_feed_abandoned_records_remaining gauge carries the same number, so the limit is visible long before it is met.
Autorizações
JWT bearer token issued by the identity provider.
Parâmetros de caminho
Feed name exactly as GET /api/v1/dict/discovery-feeds reports it.
Corpo
The record to abandon, exactly as GET /api/v1/dict/discovery-feeds reports it in heldBacenRecordIds. Two shapes appear there: a BACEN resource UUID this deployment permanently refuses, and the raw identifier BACEN sent for an entry whose id is not a UUID at all. Both are accepted verbatim; neither is interpreted.
Why this regulated record is being given up. It is recorded in the audit trail under the caller's identity and is the only durable answer to 'why does this deployment not hold that record'. Operator prose only — never a tax id, a Pix key, an account or a holder name.
8 - 384Resposta
OK
How many records are now permanently abandoned on this feed.
1
The record, as supplied.
The feed the record was abandoned on.
"dict_infraction_discovery"
States plainly that the record is now permanently absent from this deployment.
True when this record had already been abandoned. The call is then a no-op on the ledger, still audited under the caller's identity — re-sending the same request is safe.
The records this feed was still stuck on when this call read the list, minus the one just abandoned. Empty means the next tick can move — unless the feed also carries a durable blocked marker, which is cleared separately on POST .../{feed}/unblock. A walk tick running alongside this call may already have found more; GET /api/v1/dict/discovery-feeds is always the current list.

