Skip to content

Resolve by domain key

Resolving from anywhereHTTPSDKCLIMCPresolveByMetadataresolve_by_metadata

A caller that knows only orderId resolves the right row in one atomic statement, with no lookup of the escalation id first.

The situation

The warehouse system emits “order ORD-9 shipped”. It knows the order id, not the Long Tail escalation id, and a find-then-resolve pair would race with anyone else acting on the row.

The recipe

services/shipping-events.ts
const result = await lt.escalations.resolveByMetadata({
key: 'orderId',
value: 'ORD-9',
resolverPayload: { shipped: true, carrier: 'acme-freight' },
metadata: { outcome: 'shipped' },
});
if (result.status === 404) {
// no pending escalation for this order
}
The same from a terminal
ltc esc resolve-by-meta orderId ORD-9 --data '{"shipped": true}'

The lookup rides the GIN index on metadata. The statement picks the highest-priority pending row carrying the pair and resolves it.

The guarantee

Find and resolve are one statement, so there is no window for the row to change between them. RBAC is enforced in the SQL WHERE clause. A row parked by conditional wakes its workflow with the payload, and the optional metadata patch records the outcome in the same update. See Faceted routing.