Malformed legacy thread timestamps prevent server startup during V2 migration #30813

What happened

After upgrading the background service from 0.0.42 to 0.1.7, startup repeatedly failed during V2 legacy thread import. Correcting four malformed timestamp fields restored startup.

Diagnosis

Two projection_threads rows had updated_at and archived_at equal to 2026-07-13T14:13:00.3NZ. LegacyV1ThreadImporter.dateTime calls DateTime.makeUnsafe without handling invalid input, so importedThread throws and prevents server readiness. Origin of the malformed values is unknown. The same conversion remains in main. Source: https://github.com/pingdotgg/t3code/blob/v0.1.7/apps/server/src/orchestration-v2/legacy/LegacyV1ThreadImporter.ts#L189

Steps to reproduce

Observed on an existing user database:

1. Legacy threads contain updated_at and archived_at = 2026-07-13T14:13:00.3NZ.
2. Start server 0.1.7.
3. Legacy shell import throws Invalid date; launcher retries repeatedly.
4. Correct those four fields and restart: startup succeeds.
   A separate synthetic reproduction was not run. Expected: recover from malformed legacy dates or provide a targeted recoverable diagnostic.

Version

Server 0.1.7; desktop Beta 0.1.6; triage CLI 0.1.7

Environment

macOS darwin arm64 25.6.0; Node v26.12.1 for triage; launchd service; desktop and iPhone clients

Evidence

IllegalArgumentError: Invalid date
 at fromDateUnsafe
 at dateTime
 at importedThread
 at server.startup.orchestration-v2.legacy-v1.import-shells
ServerRuntimeStartupError: Server runtime startup failed before command readiness.
[service-launcher] Active child exited unexpectedly (1).
After repair: T3 Code server is ready.
Hydrated legacy v1 thread transcripts: importedThreadCount=7, importedMessageCount=54.

Related issues

#22820 covers the separate service-conflict dialog. #15920 handles unreadable legacy message context, not thread timestamps.

Fix applied or workaround

With user approval: stopped service, created and verified SQLite backup, transactionally changed only updated_at and archived_at on two rows to 2026-07-13T14:13:00.300Z, verified two changed rows and database integrity, then restarted. Original fractional seconds are unknown; .300Z is a manual approximation. Startup and legacy hydration succeeded; user reported the app working. No conversation content deleted or source patch applied.

Filed by

Codex (GPT-6) via t3 triage