What happened?
A completed PawWork session can continue to appear as running when its history contains an older assistant message without time.completed. In the observed Greeting session, the top session progress indicator stayed visible above the conversation title and the sidebar item kept showing the running spinner even though later assistant turns had completed and the latest assistant message ended with finish=stop.
Local inspection of the backing OpenCode SQLite data found one stale assistant message, msg_dafe091a7001X3Oa6sn8pBq7lc, with no time.completed, no finish value, and only step-start plus an empty reasoning part. The same session later contains multiple completed assistant messages, including a final assistant message with finish=stop and a completed timestamp. Two other nearby sessions in the same app state did not have incomplete assistant messages and did not show the same false-running evidence.
The current UI checks are broad enough that one stale historical assistant message can keep the whole session marked busy. Relevant reads in the current code are packages/app/src/pages/session/message-timeline.tsx, packages/app/src/pages/layout/sidebar-items.tsx, and packages/app/src/pages/session.tsx, where running/busy state is derived from any assistant message lacking time.completed in addition to session_status.
Steps to reproduce
- Open PawWork v0.2.4 on macOS.
- Open a session whose history contains an older assistant message without
time.completed, followed by later completed assistant turns.
- Observe the session list and session header.
Observed concrete local case: session title Greeting, session id ses_2544c191effeu1Nw5UECHonKbl, database ~/.local/share/opencode/opencode.db. The stale message was created at local time 2026-04-21 19:50:23 and the latest completed assistant message was created at local time 2026-04-21 20:09:16.
What did you expect to happen?
Once the latest run has stopped and the current session_status is idle, old incomplete assistant records should not keep the entire session marked as running forever. The top progress indicator, title spinner, sidebar spinner, and busy/follow-up logic should reflect the current turn state, not stale historical corruption.
Environment
PawWork version: v0.2.4
OS version: macOS 26.3.1 (a), build 25D771280a
Can reproduce again: Sometimes. The false-running symptom was observed in the active app session. Clicking back into the affected Greeting session later triggered the already tracked renderer crash in #94, so this issue should be treated as the false-running state bug while #94 tracks the crash path.
Extra context
This is separate from #94. During follow-up verification, clicking the same affected session reproduced the #94 renderer crash (TypeError: Cannot read properties of undefined (reading '0')), but the root evidence for this issue is the stale incomplete assistant message causing false current busy state before the crash path is hit.
What happened?
A completed PawWork session can continue to appear as running when its history contains an older assistant message without
time.completed. In the observedGreetingsession, the top session progress indicator stayed visible above the conversation title and the sidebar item kept showing the running spinner even though later assistant turns had completed and the latest assistant message ended withfinish=stop.Local inspection of the backing OpenCode SQLite data found one stale assistant message,
msg_dafe091a7001X3Oa6sn8pBq7lc, with notime.completed, no finish value, and onlystep-startplus an emptyreasoningpart. The same session later contains multiple completed assistant messages, including a final assistant message withfinish=stopand a completed timestamp. Two other nearby sessions in the same app state did not have incomplete assistant messages and did not show the same false-running evidence.The current UI checks are broad enough that one stale historical assistant message can keep the whole session marked busy. Relevant reads in the current code are
packages/app/src/pages/session/message-timeline.tsx,packages/app/src/pages/layout/sidebar-items.tsx, andpackages/app/src/pages/session.tsx, where running/busy state is derived from any assistant message lackingtime.completedin addition tosession_status.Steps to reproduce
time.completed, followed by later completed assistant turns.Observed concrete local case: session title
Greeting, session idses_2544c191effeu1Nw5UECHonKbl, database~/.local/share/opencode/opencode.db. The stale message was created at local time 2026-04-21 19:50:23 and the latest completed assistant message was created at local time 2026-04-21 20:09:16.What did you expect to happen?
Once the latest run has stopped and the current
session_statusis idle, old incomplete assistant records should not keep the entire session marked as running forever. The top progress indicator, title spinner, sidebar spinner, and busy/follow-up logic should reflect the current turn state, not stale historical corruption.Environment
PawWork version: v0.2.4
OS version: macOS 26.3.1 (a), build 25D771280a
Can reproduce again: Sometimes. The false-running symptom was observed in the active app session. Clicking back into the affected
Greetingsession later triggered the already tracked renderer crash in #94, so this issue should be treated as the false-running state bug while #94 tracks the crash path.Extra context
This is separate from #94. During follow-up verification, clicking the same affected session reproduced the #94 renderer crash (
TypeError: Cannot read properties of undefined (reading '0')), but the root evidence for this issue is the stale incomplete assistant message causing false current busy state before the crash path is hit.