fix(mobile): scheduled-task edits made in quick succession are no longer lost - #27220

Problem

In the mobile scheduled-task editor, TaskForm builds every edit from the draft prop of the last render (setDraft({ ...draft, … })), and save() submits that same captured draft. When two actions run before React commits, the second one works on the stale draft and the first edit is lost:

• Select Interval on an "At a time" task and tap Save right away: the upsert request still carries the fixed_time schedule.
• Select Interval and toggle Enabled right away: the toggle writes the old fixed_time schedule back into the editor.

Expected: every edit is kept, and Save submits what the editor holds at that moment.

Change

• setDraft now takes an updater, (current) => next, and applies it through the existing functional setEditor, so each field callback builds on the latest draft in the editor session instead of the render-time copy.
• save() reads the draft from the editor session atom (readEditor()) at the moment it runs, instead of the render-time prop.
• The webhook filter rows and the environment picker had the same problem: they built their update from rendered props. They now update the current editor too, and filters are matched by id instead of index.
• Regression tests in SettingsScheduledTasksRouteScreen.test.tsx (registered in apps/mobile/vite.config.ts) fire both actions inside one act() so React cannot commit between them: Interval → Save, Interval → Enabled, and Add filter twice. The environment picker is a Menu that this test mocks away, so it has no test of its own.

This touches only the mobile editor. Web is unaffected.

Related: #21792 handles concurrent edits across clients and edits the same save(), but it still submits the captured draft, so it does not fix this. The two changes will need a small merge in save(), whichever lands second.

Scope and approval

No prior issue. I think this fits the "very small, focused fix of an obvious bug" exception: user edits are silently dropped, the cause is a stale closure in one component, and the fix keeps behaviour and UI the same. It changes how the draft is read and written and nothing else, in a single screen file plus its test.

Verification

Regression tests: fail on main, pass with the fix. I put main's screen file in place and ran vp test run src/features/settings/SettingsScheduledTasksRouteScreen.test.tsx from apps/mobile:

note: You are running `vp test` as a Vite+ built-in command. If you meant to run the test npm script, use `vpr test` instead.

 RUN  v5.0.5 /Users/terry/Projects/tccode/apps/mobile

 ❯ |react| src/features/settings/SettingsScheduledTasksRouteScreen.test.tsx (2 tests | 2 failed) 28ms
   ❯ scheduled task batched edits (2)
     × submits the selected interval when saved before React commits 25ms
     × retains the interval when enabled changes before React commits 3ms

⎯⎯⎯⎯⎯⎯⎯ Failed Tests 2 ⎯⎯⎯⎯⎯⎯⎯

 FAIL  |react| src/features/settings/SettingsScheduledTasksRouteScreen.test.tsx > scheduled task batched edits > submits the selected interval when saved before React commits
AssertionError: expected "vi.fn()" to be called once with arguments: [ { …(2) } ]

Received:

  1st vi.fn() call:

  [
    {
      "environmentId": "environment",
-     "input": ObjectContaining {
+     "input": {
+       "creationSource": "mobile",
+       "enabled": true,
        "id": "task",
+       "interactionMode": "default",
+       "modelSelection": {
+         "instanceId": "codex",
+         "model": "model",
+       },
+       "projectId": "project",
+       "prompt": "Prompt",
        "requireExisting": true,
+       "runtimeMode": "full-access",
        "schedule": {
-         "everyMs": 3600000,
-         "type": "interval",
+         "timeOfDay": "05:00",
+         "type": "fixed_time",
+       },
+       "threadId": null,
+       "title": "Task",
+       "workspaceStrategy": {
+         "type": "root",
        },
      },
    },
  ]


Number of calls: 1

 ❯ src/features/settings/SettingsScheduledTasksRouteScreen.test.tsx:187:26
    185|     });
    186|     expect(mocks.alert).not.toHaveBeenCalled();
    187|     expect(mocks.upsert).toHaveBeenCalledExactlyOnceWith({
       |                          ^
    188|       environmentId: "environment",
    189|       input: expect.objectContaining({

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/2]⎯

 FAIL  |react| src/features/settings/SettingsScheduledTasksRouteScreen.test.tsx > scheduled task batched edits > retains the interval when enabled changes before React commits
AssertionError: expected 'fixed_time' to be 'interval' // Object.is equality

Expected: "interval"
Received: "fixed_time"

 ❯ src/features/settings/SettingsScheduledTasksRouteScreen.test.tsx:201:95
    199|       button("Toggle enabled").click();
    200|     });
    201|     expect(appAtomRegistry.get(scheduledTaskEditorSessionAtom)?.curren…
       |                                                                                               ^
    202|       "interval",
    203|     );

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[2/2]⎯


 Test Files  1 failed (1)
      Tests  2 failed (2)
   Start at  23:38:39
   Duration  882ms (environment 46%, import 35%, transform 15%, tests 3%)

note: You are running `vp test` as a Vite+ built-in command. If you meant to run the test npm script, use `vpr test` instead.

 RUN  v5.0.5 /Users/terry/Projects/tccode/apps/mobile


 Test Files  1 passed (1)
      Tests  2 passed (2)
   Start at  23:38:40
   Duration  571ms (environment 41%, import 39%, transform 14%, tests 5%)

Raw output: before, after. The filter test, added after review, fails without the filter change (expected [ { id: 'filter-2', … } ] to have a length of 2 but got 1) and passes with it. vp run check:changed passes, and so do all 61 tests in apps/mobile/src/features/settings/.

iOS simulator (iPhone 17 Pro, iOS 26.5, dev client + local dev server): reproduced on main, fixed on this branch. (Android below.)

Simulator taps land about 650 ms apart, so on an idle JS thread React re-renders between them and the bug doesn't show. On a phone the window opens when the JS thread is busy (incoming server updates, a heavy render): touches that queue up during that time are delivered to React in one batch. To make that happen without changing app code, I blocked the app's JS thread for 4 s from outside, with a busy loop sent through Metro's Hermes inspector (Runtime.evaluate, script). During the stall I tapped Interval and then Save (or the Enabled switch) through AgentDevice. Both taps landed inside the stall each time. I read the saved schedule from the dev server's database (read-only) and ran each scenario once per build.

Stalled JS thread	main	this branch
Interval → Save	Saved {"type":"fixed_time","timeOfDay":"09:00",…} at the end of the stall: the Interval choice is lost	Saved {"type":"interval","everyMs":900000}
Interval → Enabled (not saved)	Enabled is on, but the schedule is back to "At a time"	Interval and Enabled are both kept

Recordings: main and this branch. The screen freezes during the stall, so the taps only take effect once it ends.

Without a stall, the same taps save Interval correctly on both builds (main, this branch). The normal flow keeps working with the fix.

Android emulator (Pixel, API 36, locally built dev client + local dev server): same result. I used the same stall script and the same two tap sequences. Taps on Android land 110–330 ms apart. Without a stall, main still keeps Interval when Enabled is toggled right after it, so the stall is needed here too.

Stalled JS thread	main	this branch
Interval → Save	Saved fixed_time	Saved {"type":"interval","everyMs":900000}
Interval → Enabled (not saved)	Enabled on, schedule back to "At a time"	Interval and Enabled both kept

Recordings: main and this branch.

Not checked:

• A physical phone. We had a report from a real iPhone that a task saved as Interval reopened as "At a time". The simulator and emulator runs show this bug produces exactly that result when the JS thread is busy, but I have not confirmed the report comes from here.
• The stall is a stand-in for a busy JS thread. I did not reproduce the busy period with real server traffic.

Model and harness: Claude Opus 5.5 (claude-opus-5-5) in Claude Code, driven from T3 Code.

🤖 Generated with Claude Code