Fix Windows WhatsApp session-store DSN handling for SQLite init and lookup paths

[Copilot]

Windows WhatsApp bridge startup was failing during session-store migration because SQLite DSNs were built from raw Windows paths via url.URL, producing malformed file: URIs (e.g. encoded backslashes) and surfacing as SQL logic error: out of memory (1).
This change makes DSN generation Windows-safe and applies the same logic to all WhatsApp session DB open paths.

• DSN construction hardening (cross-platform)

  • Centralized session DB DSN building in internal/whatsapplive/client.go.
  • Added path normalization before URI encoding:
    • \ → /
    • Windows drive-letter absolute paths get leading / so DSN becomes file:///C:/...
  • Preserved existing pragmas:
    • read/write: _pragma=foreign_keys(1)&_pragma=busy_timeout(5000)

• Read-only helper compatibility

  • Updated direct read-only session DB opens used by:
    • lookupPNFromSessionStore
    • lookupLIDFromSessionStore
  • These now use the same normalized DSN logic with mode=ro&_pragma=busy_timeout(5000).

• Focused coverage for Windows path behavior

  • Added tests in internal/whatsapplive/client_test.go validating:
    • Windows drive-path normalization (C:\... and c:\...)
    • no encoded backslashes in resulting DSN
    • read-only DSN includes mode=ro and expected pragma.

Example of the normalized output pattern:

sessionStoreDSN(`C:\Users\Alice\openmessage\whatsapp-session.db`)
// => file:///C:/Users/Alice/openmessage/whatsapp-session.db?_pragma=foreign_keys(1)&_pragma=busy_timeout(5000)

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• instantmessaging-pa.googleapis.com
  • Triggering command: /tmp/TestBuiltBinaryAcceptsPairCommand566876082/001/openmessage /tmp/TestBuiltBinaryAcceptsPairCommand566876082/001/openmessage pair -stringintconv l/linux_amd64/vet /tmp/go-build1583251920/b358/vet.cfg rg/toolchain@v0.0.1-go1.25.0.lin-p ux-amd64/src/net/http/httptest/httptest.go ux-amd64/pkg/tool/linux_amd64/vet (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Fix the Windows-specific WhatsApp session store initialization failure in repository chz160/openmessage.

Problem

When running openmessage serve on Windows, the server starts but logs a warning when initializing the WhatsApp bridge:

Failed to initialize WhatsApp bridge for status error="open WhatsApp session store: failed to upgrade database: failed to check if foreign keys are enabled: SQL logic error: out of memory (1)"

The failure occurs during WhatsApp session store initialization in internal/whatsapplive/client.go, where the code opens a SQLite-backed whatsmeow session database using a DSN constructed by sessionStoreDSN(path string). The current implementation builds a file: URL using net/url.URL:

• sqlstore.New(context.Background(), "sqlite", sessionStoreDSN(b.sessionPath), waLog.Noop) in initClientLocked()
• sessionStoreDSN() currently returns a file: URL with _pragma=foreign_keys(1)&_pragma=busy_timeout(5000) query params

The app stores the WhatsApp DB at filepath.Join(dataDir, "whatsapp-session.db"), where dataDir defaults to filepath.Join(home, ".local", "share", "openmessage") unless OPENMESSAGES_DATA_DIR is set.

Suspected root cause

The current DSN construction likely mishandles Windows file paths when passed to the SQLite driver / whatsmeow sqlstore, causing a misleading SQLite out of memory (1) logic error during foreign key pragma checks or migration.

Relevant code

• internal/whatsapplive/client.go
• internal/app/app.go

Goal

Make WhatsApp session-store initialization work reliably on Windows without regressing Unix/macOS behavior.

Expected approach

• Investigate the SQLite DSN/path handling in internal/whatsapplive/client.go.
• Update sessionStoreDSN() and any related callsites as needed so Windows paths are encoded in a way compatible with the SQLite driver used by whatsmeow/sqlstore.
• Preserve existing pragmas (foreign_keys(1), busy_timeout(5000)) unless there is a strong reason to change them.
• Ensure any direct read-only opens of the same session DB (for helper lookups like lookupPNFromSessionStore / lookupLIDFromSessionStore) remain compatible on Windows as well.
• Add or update tests to cover Windows path handling if feasible.

Acceptance criteria

• openmessage serve no longer emits the WhatsApp session-store initialization warning on Windows for a valid writable data dir.
• WhatsApp session DB creation/open/migration works on Windows and still works on non-Windows platforms.
• Any helper functions that open the WhatsApp session DB directly also use Windows-safe path handling.
• Include tests for DSN generation or path handling logic if practical.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: When running openmessage serve on windows, the server starts fun however the console is throwing these errors message:
7:01PM WRN Failed to initialize WhatsApp bridge for status error="open WhatsApp session store: failed to upgrade database: failed to check if foreign keys are enabled: SQL logic error: out of memory (1)"

Assistant: That warning likely means the SQLite DB used by the WhatsApp bridge is failing during startup on Windows, and the bridge’s migration/init path is surfacing SQLite’s generic out of memory (1) error while checking PRAGMA foreign_keys.

I’m going to inspect the repo for the WhatsApp bridge/session-store initialization and where that exact warning is logged.

Assistant: This looks like a WhatsApp session-store initialization failure on Windows, not a failure of the main OpenMessage server.

The server is still starting because serve treats WhatsApp as optional and only logs a warning if it can’t initialize:

if !isDemo {
	if err := a.LoadAndConnectWhatsApp(); err != nil {
		logger.Warn().Err(err).Msg("WhatsApp live bridge unavailable")
	}
}

And the exact warning you saw comes from the status path here:

func (a *App) WhatsAppStatus() whatsapplive.StatusSnapshot {
	bridge, err := a.ensureWhatsApp()
	if err != nil {
		a.Logger.Warn().Err(err).Msg("Failed to initialize WhatsApp bridge for status")
		return whatsapplive.StatusSnapshot{LastError: err.Error()}
	}
	return bridge.Status()
}

The root cause is likely this SQLite-backed WhatsApp session DB open/upgrade step:

func (b *Bridge) initClientLocked() error {
	if b.client != nil {
		return nil
	}
	container, err := sqlstore.New(context.Background(), "sqlite", sessionStoreDSN(b.sessionPath), waLog.Noop)
	if er...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created from Copilot chat.*
>

[Copilot]

Pull request overview

This PR fixes Windows failures when opening/migrating the WhatsApp session-store SQLite DB by ensuring file: DSNs are built from Windows-safe, normalized paths, and by reusing that same DSN logic for read-only lookup opens.

Changes:

• Centralized DSN construction via sessionStoreDSNWithQuery, normalizing Windows paths (\ → / and /C:/... prefixing) before building file: URLs.
• Added a dedicated read-only DSN helper (mode=ro + busy_timeout) and updated session-store lookup helpers to use it.
• Added tests to validate Windows drive-path normalization and read-only DSN query behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
internal/whatsapplive/client.go	Normalizes Windows paths for SQLite file: DSNs and reuses the same logic for read-only session DB opens.
internal/whatsapplive/client_test.go	Adds test coverage for Windows path normalization and read-only DSN query parameters.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.