Session permanently unresponsive when message timestamps are ~7h ahead of real wall clock time Repository: anomalyco/opencode #26159

Description

Title: Session permanently unresponsive when message timestamps are ~7h ahead of real wall clock time
Repository: anomalyco/opencode
Version: 1.14.39
Platform: Linux Manjaro ( timezone: UTC+8 )

Summary

A session became permanently unresponsive after some of its messages were recorded with timestamps approximately 7 hours ahead of real wall-clock time. The user could not continue the conversation in that session. Forking the session did not help. After manually correcting the timestamps in the SQLite database back to reasonable values, the session resumed normal operation.

Related Issues

• Web UI: client-generated message IDs cause infinite processing loop when client/server clocks diverge #11863 — Client-generated message IDs cause infinite loop when clocks diverge
• Clock skew between client and server breaks prompt loop and message rendering #14236 — Clock skew breaks prompt loop and message rendering
• Bug: Message ordering broken when client clock is out of sync with server #15657 — Message ordering broken when client clock is out of sync
• Crash on time change #12740 — Crash on time change
• TUI freezes for ~10 seconds periodically on WSL2 (regression in v1.0.129) #5361 — TUI freezes on WSL2 due to clock adjustments
  These all involve timestamp-related assumptions. This issue is distinct in that:
• It occurred in a TUI local session (no client/server split)
• The timestamps were recorded ~7 hours ahead of real time
• The session became permanently stuck, not just temporarily glitched
• The session_read API also failed for the affected session

Reproduction

Exact trigger for the timestamp offset is unclear. The following was observed:

1. Started an OpenCode session, used the AIgora skill to generate a long discussion output (~125KB across 4 assistant messages)
2. The AIgora output completed successfully
3. Attempted to continue the conversation with follow-up messages — no assistant responses were generated. The session appeared completely stuck.
4. Inspected the conversation in TUI — newly sent messages appeared in the history, sorted before the earlier AIgora exchange, instead of appearing after it as the latest messages
5. Forking the session produced no improvement
6. Later discovered via database analysis: the AIgora messages had timestamps ~7 hours ahead of real time, so any new (correctly timestamped) messages sorted "before" them and were treated as historical rather than new input

Observation (Database Analysis)

From ~/.local/share/opencode/opencode.db:
Session metadata — time_updated pointed ~7 hours into the future:

session.time_updated:  2026-05-07T16:45:00 UTC (= next day 00:45 local time)
current wall clock:    2026-05-07T09:40 UTC (= same day 17:40 local time)
=> session time_updated is ~7 hours AHEAD of real time

Message timestamps — first batch correct, second batch in future:
Earlier messages (user testing messages):

msg_001 | 2026-05-07 08:55:27 UTC → 16:55 local  ✓ CORRECT
msg_002 | 2026-05-07 08:55:38 UTC → 16:55 local  ✓ CORRECT
...
msg_026 | 2026-05-07 09:21:52 UTC → 17:21 local  ✓ CORRECT

AIgora messages (1 user prompt + 4 assistant responses):

msg_027 | 2026-05-07 16:44:06 UTC → 00:45+1 local  ✗ ~7h AHEAD
msg_028 | 2026-05-07 16:44:06 UTC → 00:45+1 local  ✗ ~7h AHEAD
msg_029 | 2026-05-07 16:44:24 UTC → 00:45+1 local  ✗ ~7h AHEAD
msg_030 | 2026-05-07 16:44:47 UTC → 00:45+1 local  ✗ ~7h AHEAD
msg_031 | 2026-05-07 16:45:00 UTC → 00:45+1 local  ✗ ~7h AHEAD

Any new message sent after the AIgora output would get a correct timestamp (~09:40 UTC), which sorts before the AIgora messages (~16:44 UTC). This explains why new messages appeared "in history" — they were ordered before the future-timestamped AIgora exchange.
The ~7h offset appeared suddenly between the two groups of messages. The real elapsed time between msg_026 and msg_027 was likely only a few minutes, not 7+ hours.
session_read failure: The session_read API returned "Session not found" for this session, despite session_info and session_search working correctly. The session's project_id was global and directory differed from the current project, which may also contribute.

Fix

Manually corrected the following fields in the SQLite database:

• message.time_created and message.time_updated for all 5 AIgora messages
• message.data JSON field $.time.created
• part.time_created and part.time_updated for all associated parts
• session.time_updated
  Also deleted the 26 orphan user messages (user-only, no assistant response, from earlier testing).
  After these corrections, the session immediately resumed normal operation.

Suggested Improvements

1. Handle anomalous timestamps gracefully: If a session's timestamps are detected to be significantly ahead of wall clock time, the session should not become permanently stuck. Consider logging a warning and continuing operation.
2. session_read resilience: Investigate why session_read fails while session_info and session_search succeed for the same session — this may be a separate bug related to project scoping.

Plugins

No response

OpenCode version

1.14.39

Steps to reproduce

Sorry, I have no idea why timestamps moved. But the bug happens.

Screenshot and/or share link

No response

Operating System

Linux 6.12.85-1-MANJARO

Terminal

Konsole