Carlos Florêncio
b9eb6ae058
* refactor(web): remove legacy settings migration * fix(web): hydrate portable settings from boot state * fix(web): preserve sidebar sync contracts * fix(web): retain portable settings filters * fix(web): retry sidebar settings writes * fix(web): retain sidebar boot settings * fix(websocket): avoid shutdown teardown leaks * fix(boot): normalize sidebar task preferences * fix(settings): preserve saved views during hydration * fix(jira): avoid duplicate saved-view syncs * fix(jira): preserve saved views on fetch failure * fix(jira): retry saved-view hydration failures * refactor(jira): simplify hydration request cleanup * fix(websocket): close late clients after hub shutdown
2.1 KiB
0028: Backend-Owned Task-Create Last-Used Preferences
Status: accepted; browser-cache portion superseded by 0041 Date: 2026-06-29 Area: backend, frontend
Context
The task-create dialog restores the user's last repository, branch, agent profile, and executor profile. Those values were partly kept in browser localStorage and partly in backend user settings, which allowed stale localStorage to win while backend settings were still loading. Auto-picked defaults also were not saved unless the user manually changed a selector.
Decision
Backend user settings are the durable source of truth for task_create_last_used. Successful task creation records the final values used by the backend. The original browser-cache compatibility path was removed by ADR 0041 after the migration window. Dialog auto-selection now uses backend settings only; an in-memory queued overlay may bridge an in-flight task-create response without becoming a second durable store.
Task-create preference writes use targeted JSON updates under users.settings.task_create_last_used, and broad user-settings writes preserve the current task-create preference instead of rewriting it from a stale settings blob.
Consequences
The next task-create dialog reflects the choices that actually created the previous task, including auto-picked defaults. Settings writes no longer erase newer task-create preferences when they race with task creation. The frontend may show an empty/loading selector state slightly longer while waiting for user settings, but avoids restoring stale localStorage values.
Alternatives Considered
- Persist inside frontend auto-pick effects. Rejected because auto-pick runs during data-loading and compatibility settling; saving there would make transient fallbacks durable.
- Keep localStorage as the primary source. Rejected because it cannot be read by the backend, can be stale across database resets or workspace changes, and does not publish updates to other clients.
- Use the existing broad user-settings PATCH only. Rejected because the read/merge/write path can clobber newer task-create values when unrelated settings writes overlap.