Know who resolved it

The escalation boundaryDashboardHTTPSDKMCPScanconditional$resolutionresolved_by

The resolver's identity rides the wake as $resolution and lands on the row as resolved_by, so follow-on work can go to the same person.

The situation

The person who approved an order should also pack it. The workflow needs the approver’s user id from the resolve itself, not from a second lookup that can race.

The recipe

import { conditional, type EscalationResolution } from '@hotmeshio/long-tail';

const decision = await conditional<{ approved: boolean; $resolution?: EscalationResolution }>(signalId, {
  role: 'order-reviewer',
  metadata: { orderId },
});

if (decision && decision.$resolution) {
  const { escalationId, resolvedBy, resolvedByEmail } = decision.$resolution;
  await assignPacking({ orderId, userId: resolvedBy });
}

/escalations/available?status=resolved&facets={"resolved_by":"{lt:me}"}&orderBy=[{"field":"resolved_at","direction":"desc"}]

Declare $resolution in the generic to read it. The same resolve merges resolved_by into the row’s GIN-indexed metadata, which the built-in {lt:me} link variable reads.

The guarantee

$resolution carries escalationId, resolvedBy and resolvedByEmail when known. It rides the signal only: the stored resolver_payload keeps the form payload untouched. Every completing resolve records metadata.resolved_by, including batch fills, both rows of an accumulate add and scan acts. See Conditional.

The escalation boundary