Question 1

Why is the Specialist Marketplace "Browse Marketplace" button disabled in Remote Web but works in the desktop app?

Accepted Answer

In v0.35.1 and current `main`, `specialist.listMarketplace` and `specialist.getMarketplaceRelease` are declared with the `ELECTRON` profile in `src/shared/renderer-contracts/specialist.ts`. The web RPC layer only exposes web-profiled channels, so `/rpc/specialist:marketplace-list` returns HTTP 404 `method_not_found`. The corresponding application commands are also missing, causing the renderer to disable the button in Remote Web.

Immediate workaround: open Settings → Specialists in the desktop application, where the Marketplace is available.

Permanent fix:
1. Change `specialist.listMarketplace` and `specialist.getMarketplaceRelease` from the `ELECTRON` profile to `WEB`.
2. Regenerate `web-api-map.generated.ts` using `scripts/generate-web-api-map.mjs`.
3. Register `specialist:marketplace-list` and `specialist:marketplace-release-get` in `src/main/specialist/application-commands.ts`.
4. Keep Electron-only Marketplace actions—source management, install, cancel, and download progress—gated so Remote Web remains read-only.
5. Deploy the patched build or upgrade to a release containing PR "fix(specialist): support Marketplace browsing in Remote Web".

Question 2

How to fix 'Backend shutdown did not complete cleanly' error when quitting via Dock on macOS?

Accepted Answer

This affects version 1.0.1 on macOS: after using Notebook, Dock Quit fails because Python/REPL kernel processes are left with unresolved ownership status ('ownership-candidate-unresolved'), which blocks clean backend shutdown and cancels the quit. It is not a timeout issue. The fix landed in PRs #3797 (exclude foreign macOS process coalitions before admitting ambiguous ownership) and #3877 (avoid permanent ambiguity when a validated foreign process exits or is reused). Update to a build containing these changes — verified fixed on main branch commit b45bd3657 and later. After updating, retest Notebook → Dock Quit (including repeated quit attempts) and confirm the warning no longer appears and all Notebook processes are stopped.

Question 3

How to fix Open-Science quitting with "credential access failed" on Linux GNOME Keyring?

Accepted Answer

This affects Open-Science 0.34.0–0.36.0 with gnome-keyring 50.0. The app starts multiple short-lived `busctl` Secret Service probes on every settings load/credential operation; gnome-keyring can race on these clients, return a transient D-Bus error, or abort, and the app treats that as fatal and exits with `credential access failed`.

Fix: upgrade to an Open-Science build containing the fix for issue #3386, "stop redundant Linux backend probes after first secret operation." After the first successful encryption check, the result is cached instead of repeatedly probing gnome-keyring.

Immediate recovery if gnome-keyring restarted with the Login keyring locked:
1. Log out and back in, or open **Passwords and Keys** and unlock the **Login** keyring.
2. Verify it is unlocked:
   `busctl --user get-property org.freedesktop.secrets /org/freedesktop/secrets/collection/login org.freedesktop.Secret.Collection Locked`
   It should report `b false`.
3. Restart Open-Science.

If the daemon is in a bad state, restart it with `systemctl --user restart gnome-keyring-daemon.service`, then unlock the Login keyring before relaunching the app. Upgrading is required to prevent the recurring race.

Question 4

How to fix Ctrl+F not opening find in an empty conversation on Windows?

Accepted Answer

This was fixed in merged PR #3316 (commit `f78618d5b`). The new-conversation layout stopped mounting `WorkspaceMessageScroller`, so an empty workspace did not announce find readiness or subscribe to the main-process show request; as a result, Ctrl+F on Windows (Cmd+F on macOS) did not open the native whole-window find overlay. Update to a build containing commit `f78618d5b`, rebuild/restart the app, and retry Ctrl+F from the empty conversation.

Question 5

How do I fix 'Specialist switching is unavailable' when changing a conversation's Specialist in Remote Web?

Accepted Answer

This happens because `specialist.setSessionSpecialist` is declared as an Electron-only RPC, so `window.api.specialist.setSessionSpecialist` is `undefined` in Web builds. Idle sessions silently revert, while running sessions show the reconfigure failure banner.

The permanent fix is to expose the existing switch handler to the Web surface:

1. Update `src/shared/renderer-contracts/specialist.ts` so `specialist.setSessionSpecialist` is no longer restricted to the `ELECTRON` profile.
2. Register the corresponding `specialist:set-session-specialist` application command in `src/main/specialist/application-commands.ts`, using the same Web command seam as `specialist:update` and `specialist:set-enabled`.
3. Inject and call `SessionSpecialistReconfiguration.requestSwitch` from that command handler.
4. Regenerate `src/shared/web-api-map.generated.ts`.
5. Update `src/shared/renderer-surface-matrix.test.ts` so the channel is expected to be available on Web.

On unpatched versions, the workaround is to switch Specialists from the desktop Electron app; the Web picker cannot rebind an existing session until this fix is deployed.

open-science

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects