fix(process): graceful shutdown on Linux/Windows to prevent conversation loss

[abhijeetatgit]

Summary

Fixes #167 — Chat history lost when switching accounts.

Root Cause

The Manager was force-killing the IDE process (SIGKILL) before it could flush its SQLite WAL journal (state.vscdb), causing conversation data loss on every account switch.

Changes

src/modules/antigravity-runtime/ipc/handler.ts

• Linux: Use wmctrl -c to trigger the IDE's internal before-quit event, giving it time to flush SQLite. Falls back gracefully if wmctrl is not available.
• Windows: Use taskkill without /F flag for graceful termination before force-killing.
• All platforms: Replace immediate SIGKILL with SIGTERM → 15-second grace period → SIGKILL fallback. This gives the IDE time to commit pending writes.

src/modules/cloud-account/persistence/cloudHandler.ts

• Add PRAGMA wal_checkpoint(TRUNCATE) when opening the IDE database in write mode, ensuring any pending WAL data is committed to the main database file before reads/writes.

Testing

• Verified on Linux (Ubuntu) with multiple account switches — conversations now persist across switches.
• Graceful shutdown completes within 2-3 seconds on average; SIGKILL fallback only triggers if the IDE hangs.

[codereviewbot-ai]

Insufficient Error Logging in Platform-Specific Shutdown

The catch blocks for AppleScript (macOS), taskkill (Windows), and wmctrl (Linux) do not log the actual error details, only generic warnings. This can hinder debugging and root cause analysis if the shutdown fails unexpectedly.

Recommendation:
Log the error object in the catch block for each platform-specific shutdown attempt:

catch (error) {
  logger.warn('AppleScript exit failed, proceeding to next stage', error);
}

Apply similar changes for Windows and Linux catch blocks.

[codereviewbot-ai]

Potential Data Consistency Issue:

The WAL checkpoint operation (result.raw.pragma('wal_checkpoint(TRUNCATE)')) is performed without retry logic for busy errors. If the database is busy, the checkpoint may fail, and only a warning is logged. This could lead to stale reads or missed data consistency guarantees, especially after an unclean IDE shutdown. Consider implementing retry logic similar to other SQLite operations:

for (let attempt = 1; attempt <= SQLITE_MAX_RETRIES; attempt++) {
  try {
    result.raw.pragma('wal_checkpoint(TRUNCATE)');
    break;
  } catch (e) {
    if (isSqliteBusyError(e) && attempt < SQLITE_MAX_RETRIES) {
      sleepSync(SQLITE_RETRY_DELAY_MS);
      continue;
    }
    logger.warn('Failed to checkpoint WAL for IDE db', e);
    break;
  }
}

This would improve reliability and data consistency.