Files
searchi/docs/SINGLE-INSTANCE.md
T

57 lines
3.3 KiB
Markdown

# Desktop launch behavior
Launching searchi again shows, restores and focuses the existing main window,
then focuses its search field through the existing `focus-search` event. It does
not interpret arguments, open supplied files, or start another index/model session.
The [official Tauri single-instance plugin](https://v2.tauri.app/plugin/single-instance/)
is registered first, before other plugins and application setup. Its native
transport provides duplicate detection; searchi does not maintain its own mutex.
Normal launches retain `dev.searchi.desktop`. An explicit absolute
`SEARCHI_DATA_DIR` creates an isolated desktop profile. Before plugin setup,
searchi resolves its canonical existing ancestor and any missing suffix without
creating the directory, then appends a SHA-256 of its native path
bytes to the runtime identifier. Windows uses UTF-16 units; Unix uses raw path
bytes. The identifier does not disclose the profile path. This also isolates
identifier-derived WebView/app-data locations. Same canonical profiles converge;
different profiles can run concurrently. This override is a developer/portable
profile mechanism, not a command-line search interface.
The plugin owns its Windows mutex, Linux D-Bus registration, or macOS socket.
Independent Linux D-Bus sessions have independent instances. Snap/Flatpak need
the upstream-documented D-Bus permissions; those packages remain unvalidated.
The previously published v0.1.0 application predates this change and cannot be
retroactively notified by the plugin.
## Validation
- Unit checks cover unchanged normal identity, rejected relative profiles,
Unicode profile paths, canonical aliases, stable/different identities and
absence of readable paths in identifiers.
- Native duplicate-launch behavior and window restoration require a running
desktop; platform evidence is recorded separately from unit checks.
- Windows VM inference tests must force CPU. No native macOS/Linux duplicate
launch or GPU claim is implied by the implementation.
### Windows VM evidence, 2026-10-13
- Desktop tests: 35 passed. Final strengthened profile tests: 2 passed.
Strict desktop all-target Clippy and formatting passed.
- Owned custom-protocol debug executable SHA-256
`93a22d5949fc0837f23e8455497b11333499bf41a5650b3f88493d5142de627f`.
- Fresh isolated profile A launched as PID 10624 using the normal bundled
worker SHA-256 `c01cb3ec13cfca722ee768e8350e1399a8b9a4d14a24a35adc3473a5cfc82a73`.
Its genuine Google CPU query worker PID 14520 remained identical before and
after duplicate PID 19240 exited successfully with code 0. The worker command
retained `--threads 1 --device cpu --role query`.
- Concurrent distinct profile B PID 12096 remained alive alongside profile A.
Profile B deliberately used an unavailable worker to avoid another inference
model; this proves desktop profile isolation, not semantic readiness there.
- Only owned test process trees were terminated afterward. Installed user app
PID 7716 remained alive and was never upgraded, focused or terminated by the
test. Raw local evidence: `.searchi/qa/single-instance/normal-result.json` and
`isolation-result.json` (ignored).
- This is process/lifecycle evidence. Native visual focus, restoration of a
minimized window and frontend search-field focus remain unverified.