fix: stop "subjects have already been set" during pre-checkin

Confirming subject selection failed for anyone who used the back button.
base:selectSubjects wrote CheckinSubject rows but its onStepRollback was an
empty stub, so goBack deleted the step data and left the rows behind. On the
re-run, setSubjects saw existing rows and threw. The pre-checkin flow renders a
back button on every screen and has two informational steps right after subject
selection, so this was easy to hit.

- selectSubjects: clear subjects on rollback instead of no-op.
- setSubjects: replace the set in a transaction rather than throwing. Resolves
  the TODO there. Safe because nothing downstream of subject selection has run
  yet, and it also unsticks sessions that died between setSubjects and
  setCompleted -- those hit the error on every retry via the resume path.
- SelectSubjectScreen: block double submits, which could otherwise put two
  confirmSubjects calls in flight before the step advanced.

Also guard goBack against completed/aborted sessions. Rollback hooks undo real
side effects, and step:goBack can be sent directly (admin debug panel) even
though the kiosk hides the button once the session finishes. undoCheckin stays
the one way to reverse a finished check-in.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: scriptcoded

packages/backend/src/core/workflow/step.ts

@@ -1,3 +1,4 @@
+import { prisma } from "../../app/prisma.ts";
 import {
   deleteStepData,
   findLastCompletedStep,
@@ -79,6 +80,25 @@ export async function goBack(
     throw new Error("No session ID found in context");
   }
 
+  // A finished session is a durable record, not something to unwind: rollback
+  // hooks undo real side effects (subject links, check-in timestamps), so
+  // walking backwards through one would quietly damage a completed check-in.
+  // The kiosk hides its back button once `session:completed` arrives, but
+  // `step:goBack` can still be sent directly (see the admin debug panel), so
+  // the guard belongs here rather than in the UI. Use undoCheckin to reverse a
+  // finished check-in.
+  const session = await prisma.checkinSession.findUniqueOrThrow({
+    where: { id: sessionId },
+    select: { completedAt: true, abortedAt: true },
+  });
+  if (session.completedAt || session.abortedAt) {
+    getLogger(c).warn(
+      { completedAt: session.completedAt, abortedAt: session.abortedAt },
+      "Ignoring goBack for a session that is already completed or aborted",
+    );
+    return;
+  }
+
   // Walk backwards, skipping steps marked skipOnGoBack.
   const maxSteps = 100;
   for (let i = 0; i < maxSteps; i++) {

packages/backend/src/core/workflow/stepContext.ts

@@ -224,25 +224,24 @@ export function createStepContext(
         throw new Error("No session ID found in context");
       }
 
-      const existingSubjects = await prisma.checkinSubject.findMany({
-        where: { checkinSessionId: sessionId },
-      });
-
-      if (existingSubjects.length > 0) {
-        // TODO: Can we handle this gracefully? We could delete old subjects and
-        // set new ones, but that could have unintended consequences. Maybe we
-        // should just let the user start a new session?
-        throw new Error(
-          "Subjects have already been set for this session, cannot set again",
-        );
-      }
-
-      await prisma.checkinSubject.createMany({
-        data: participantIds.map((participantId) => ({
-          checkinSessionId: sessionId,
-          participantId,
-        })),
-      });
+      // Idempotent by design: the same set can legitimately be submitted twice.
+      // A rollback to the selecting step leaves the old rows behind, and a
+      // double-tapped submit sends two calls before the step advances (the
+      // stale-method guard in session.socket.ts only catches calls arriving
+      // after advancement). Replacing the set is safe here because no step
+      // after subject selection has run yet — anything that acts on subjects
+      // runs downstream and will see the new set.
+      await prisma.$transaction([
+        prisma.checkinSubject.deleteMany({
+          where: { checkinSessionId: sessionId },
+        }),
+        prisma.checkinSubject.createMany({
+          data: participantIds.map((participantId) => ({
+            checkinSessionId: sessionId,
+            participantId,
+          })),
+        }),
+      ]);
     },
     async clearSubjects() {
       const sessionId = c.get("wsSessionId");

plugins/base/src/selectSubjects/backend/selectSubjects.ts

@@ -66,8 +66,11 @@ export const selectSubjects: StepImplementation = {
         subGroups,
       });
     },
-    async onStepRollback(_ctx) {
-      // await ctx.clearActor();
+    async onStepRollback(ctx) {
+      // Rolling back deletes this step's data but not the subject rows it
+      // wrote, so they must be cleared here — otherwise the re-run selection
+      // is layered on top of the previous one.
+      await ctx.clearSubjects();
     },
   },
   publicMethods: {

plugins/base/src/selectSubjects/frontend/screens/SelectSubjectScreen.tsx

@@ -63,6 +63,7 @@ export function SelectSubjectScreen({ payload }: { payload: object }) {
 
   const validPayload = Payload(payload);
 
+  const [submitted, setSubmitted] = useState(false);
   const [selectedParticipantIds, setSelectedParticipantIds] = useState<
     string[]
   >(() => {
@@ -118,6 +119,12 @@ export function SelectSubjectScreen({ payload }: { payload: object }) {
   };
 
   const submitSelected = () => {
+    // Guard against double-tapping: two confirmSubjects calls can otherwise be
+    // in flight at once, before the backend has advanced the step. The screen
+    // unmounts on step advancement, so this never needs resetting.
+    if (submitted) return;
+    setSubmitted(true);
+
     socket?.send({
       name: "step:callMethod",
       data: {
@@ -218,7 +225,7 @@ export function SelectSubjectScreen({ payload }: { payload: object }) {
             variant="primary"
             icon={ArrowRightIcon}
             iconPosition="after"
-            disabled={selectedParticipantIds.length === 0}
+            disabled={selectedParticipantIds.length === 0 || submitted}
             onClick={submitSelected}
           >
             {t("submit", {