Un-park operations held after exhausting their outbound attempt budget

Clears the outbound transmit claim of the named operations, returning them to the eligible backlog so the next drain tick re-drives them. RBAC: connectivity:admin. It is the ONLY recovery path for a PARKED operation. BOTH outbound stages park for the SAME reason, reported in parkReason as attempt_budget_exhausted: N consecutive counterpart refusals exhausted the operation’s attempt budget (SCHEDULE_DISPATCH_MAX_TRANSMIT_ATTEMPTS, default 20). What differs is the stage and the state left behind, which the alert reports in stage: a FORWARD file (ASLC022/024/032/061/065 to the IF Domicilio) leaves the operation ACCEPTED, re-driven by the forward tick; a DISPATCH file (ASLC027/029/031/060/064 to Núclea) leaves it QUEUED, re-driven by the dispatch tick. The value permanent_rejection is RETIRED and no longer emitted - no single 4xx response carries the evidence to park a file - but historical alerts still carry it. Either way the held claim makes it invisible to every drain, and every other admin verb is a dead end: /advance rejects the no-op self-edge, /requeue is CREATED-only, /retry is REJECTED-only, and /retransmit either rejects the state (a parked forward op is ACCEPTED, not QUEUED) or loses its own claim CAS and answers 409 in-flight (a parked dispatch op IS QUEUED). Enumerate the ids with GET /v1/operations?transmitHold=parked, which is the authoritative, paginated, tenant-scoped list; the operation.forward_rejected alert (payload operationIds) and the park’s ERROR log field parked_operation_ids are first-response excerpts of the same set, and the daily webhook names only the first file parked that day. There is no scope-wide form: a held transmit claim is AMBIGUOUS between a parked operation and one whose file is already at Núclea, and only the caller decides which set to release. This verb REFUSES the second kind with 409 when it is marked as such (transmitHold=in_flight) - reconcile those with Núclea and drive each one with POST /v1/operations//advance instead, never un-park them. Idempotent: re-running releases nothing further and reports released=0. Claims younger than the 5-minute safety floor are skipped (they may belong to a pass that is mid-submit). Un-parking also zeroes the attempt budget, so a recovered operation gets a full budget rather than re-parking on its next refusal. Runs lock-free: it transmits nothing.

POST /v1/connectivity/unpark

Un-park operations held after exhausting their outbound attempt budget

cURL

curl --request POST \
  --url https://slc.sandbox.lerian.net/v1/connectivity/unpark \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "operationIds": [
    "<string>"
  ],
  "confirmedNotAtNuclea": true,
  "reason": "<string>"
}
'

200

{
  "action": "<string>",
  "released": 123,
  "requested": 123,
  "skipped": 123
}

Authorizations

Authorization · string · header · required

JWT bearer token issued by the identity provider.

Body

application/json

operationIds · string[] | null · required

Parked operation ids to un-park. Enumerate them with GET /v1/operations?transmitHold=parked, which is the authoritative, paginated, tenant-scoped list; the operation.forward_rejected alert (payload operationIds) and the park's ERROR log field parked_operation_ids are first-response excerpts of the same set. 1..500 UUIDs.

Example:

["018f8a3e-4b2c-7c1a-9e5d-2f6a1b3c4d5e"]

confirmedNotAtNuclea · boolean

Set ONLY after reconciling with Núclea and confirming the file was NOT accepted. Without it, an operation whose transmit hold is in_flight is refused with 409, because releasing it would re-submit an accepted settlement file. With it, those ids are released too and the decision is logged at ERROR with your reason. Núclea's synchronous 202 means "accepted for processing", not settled, so this case is real - but it is the caller's finding, never a default.

Example:

false

reason · string

How it was confirmed that Núclea did not accept the file. REQUIRED when confirmedNotAtNuclea is true; it is the audit record of who decided to release a possibly-in-flight settlement.

Example:

"Núclea support ticket 48210: file ASLC022_62313268_20260724_00006 not received; no NUliquid issued."

Response

200

application/json

OK

action · string · required

Recovery action that was executed.

Example:

"unpark"

released · integer<int64> · required

Transmit claims actually cleared; these operations are back in the eligible backlog.

Example:

2

requested · integer<int64> · required

Distinct operation ids named in the request.

Example:

3

skipped · integer<int64> · required

Ids that carried no transmit claim (never parked, or already un-parked) or whose claim is younger than the safety floor.

Example:

1