Hand back a running step without settling it

The step's claim, exactly as the claim handed it out.

Why a browser handed back a step it holds without settling it.

verified_absent: it looked and found the step not done, and may not finish it now (a held or cancelled step's look). reopen_paused: the person closed the working tab again, so this browser stopped reopening it. Neither counts against the step: a run cut off under it is reported as an attempt instead.

When the step said it acted on LinkedIn, for a result that arrived late. On a failed step it means the step happened after all: it stays failed for a person, and a Retry checks LinkedIn first and never sends it twice.

When the step was let run: the moment it was queued, since a step is queued only once it may run. Kept for older extension builds.

Why one action did not succeed, as a closed vocabulary.

Two populations in one enum, on purpose. The first twelve are reported by the browser agent and were previously a free string that only the extension had written down, so nothing stopped a typo storing and rendering exactly like a real code. The last four the backend writes itself: three when an action settles without the browser ever running it, and CLAIM_EXPIRED when the browser took a step and then went silent, so nobody can say whether it ran.

The list is the whole contract: a code outside it is rejected at the API boundary rather than persisted, so the extension and the dashboard can only ever speak about failures both sides can name.

Whether the step is held out of every browser's line, because its paused sequence or paused contact holds it. It runs once they are resumed. Only the dashboard's queue lists a held step that is waiting; a browser is never sent one.

Why a sequence's step may not run now, whatever its approval says.

A paused sequence or a paused contact sends nothing on either channel; an approval given meanwhile waits for Resume sequence (or the contact's own resume).

What the browser agent is being asked to do.

The four CHECK_*/READ_* kinds are housekeeping: they read our own outbound invitations, our own newest connections and our own conversations to detect what the contact did, so they are free and deliberately excluded from the priced kinds below.

CHECK_CONNECTIONS reads the first batch of the sender's connections list, newest first: a person found there has accepted, whenever the invitation went out. It is how an acceptance is noticed at all once an invitation has fallen out of the ten rows the sent list shows a background tab.

CHECK_INBOX scans the conversation list for threads with new inbound activity; READ_CONVERSATION opens one of them and reads it in full. The split keeps LinkedIn activity proportional to real replies: the cheap scan runs on every sweep, the expensive read only where the scan saw a change.

LIKE_LATEST_POST targets the contact's most recent post at the moment the browser runs it. A contact with no posts is not a failure: the driver reports the action SKIPPED, and the sequence advances either way.

Every profile-targeted outcome carries the facts the browser read off the profile, including the three-state Premium "Open Profile" reading; see the section comment above the outcome models.

Whether the step spends the sender's limits and credit. False for a step the Oneprofile team fired to test the sender: it goes first, waits for no gap and counts against no limit.

Always false: a step that asks for a person waits on Oneprofile's Tasks page, never in the line. Kept for older extension builds.

Where one queued action stands.

Governor-deferral is deliberately NOT a status: an action whose kind has hit its daily cap stays QUEUED and is simply not handed out, with the reason travelling on the hand-out response instead. A DEFERRED row would make the queue lie about what is still waiting to happen.

SKIPPED is "not applicable" (no LinkedIn URL, already connected); REJECTED is "a human refused it"; FAILED is "we tried and could not".

RESUMING is a step put back in line after an attempt that may have acted on LinkedIn (its browser was granted the press, or lost track of the step): it is never "queued", so no path that assumes nothing happened yet (moving it to another sender, a plain copy, "did not run") ever reads it as such, and it is handed only to a browser that checks LinkedIn before acting.