Attrition: detect partner dropout and abort the game loop with a payment path

[htsukamoto5]

Phase 1 — unblocked, and the highest-value attrition fix. Explicitly does not need a presence API.

The problem

The survivor of a dropout does not hang — they grind, which is worse, because it burns their time before they give up.

round_timeout sets its timer at round start. When it fires, the round ends with ended_by: "timeout" and a null assignment, feedback shows, and the timeline advances to the next round, starting a fresh timer. There is no cross-round abort and no presence check:

	per-round dead wait	rounds left if partner drops on round 1	total dead time
Hawkins	60 s	71	~71 min
C&WG	180 s	5	~15 min

And the survivor is never told anything — the plugin has no partner-status copy, no disconnected state, no UI affordance at all. They see a normal, fully interactive board that simply never responds, 72 times over. They abandon, so one dropout burns two payments and generates a support ticket.

Work

• Count consecutive ended_by: "timeout" rounds. Two or three in a row is a perfectly good dropout proxy with no presence API.
• On trip: flush data, show an honest "your partner appears to have disconnected" screen, and exit to a partial completion code so the survivor gets paid.
• Break out of the game loop properly. conditional_function on gameLoop is evaluated once, so a mid-game abort needs either a per-round conditional_function on gameRound or jsPsych.abortCurrentTimeline() from the round's on_finish.
• Record n_trials_completed so partial dyads can be filtered. The partial-data policy decision determines whether the abort path salvages or discards.

There is an upgrade path to real disconnect detection once a presence API exists, but this work should not wait on it.

See READINESS.md section 2.

[htsukamoto5]

Suggested abort-path flow

Recording the flow settled while working through the payment and consent questions. Tentative, but concrete enough to build against. Nothing here changes the detection heuristic already in the issue body.

The key structural point: incremental saving makes this robust, not the flush

The obvious worry with "flush data, then pay" is that it makes payment depend on a network call succeeding — a slow or failed save would strand the survivor on a screen with no completion code, recreating the exact dead end this issue exists to remove.

The answer is not to make the flush reliable. It is to make it nearly empty. If #3 saves per round rather than on on_finish, then by the time an abort fires almost everything is already at the save target and the final flush carries at most one round. This is the main reason #3 should be built incrementally, and it should be treated as a dependency of this issue rather than merely adjacent to it.

Flow

1. Detect. N consecutive rounds with ended_by: "timeout" (2–3 is a reasonable proxy). Upgrade path to real presence detection is Verify whether adapter-multiplayer-firebase exposes presence / onDisconnect #11 — do not wait on it.
2. Fire the flush and show the screen in parallel. Do not await the save before rendering the exit screen or before making the completion code available.
3. Screen copy is honest and immediate: the partner appears to have disconnected, this is not the participant's fault, they will be paid for what they did, here is how to submit. No blame, no ambiguity about payment.
4. Redirect on save-complete or on a short timer, whichever comes first. The redirect must be guaranteed regardless of save outcome. A failed save costs one round of data; a blocked redirect costs a support ticket and an unpaid participant.
5. Exit via the partner-dropped completion code (Prolific plumbing: completion codes and submission redirect #7).
6. Record n_trials_completed so partial dyads are filterable, per Decide: are partial (aborted) dyads usable for analysis? #8.

Do not re-consent on the abort path

It is tempting to ask the stranded survivor whether their partial data may still be used. Suggested position is no — consent is taken once, up front.

A post-hoc opt-in is a selection filter, and a biased one: stranded survivors are likelier to decline than completers, and being stranded correlates with the DV (longer, more effortful sessions), so re-consenting only on this path would preferentially delete the high end of the measure. It also applies a standard that completers are not held to. See the ethics section of READINESS.md — this is flagged as a question for IRB, and if they prefer re-consent it must be offered identically to every participant rather than only to those whose partner left.

Breaking out of the loop

Unchanged from the issue body, but worth restating since it is the easiest part to get wrong: conditional_function on gameLoop is evaluated once, so it cannot end a game already in progress. A mid-game abort needs either a per-round conditional_function on gameRound or jsPsych.abortCurrentTimeline() called from the round's on_finish.

The participant who dropped

They closed the tab, so there is no redirect and no completion code for them, and they have most likely returned the study — which is the correct outcome and carries no payment.

Worth noting the escape hatch though: with #4 (PROLIFIC_PID on every row) plus incremental saving, their partial rows exist even though they never submitted. So they can be identified and paid a manual bonus if that is judged appropriate. That option exists only if #3 and #4 are both done.