Plugin api

[Jordonbc]

No description provided.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 218c43c5bb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Review

• Frontend/src/scripts/features/settings.ts:341 – openSettings still logs console.log('Opening settings modal…') every time the dialog opens. That pollutes the production console and is leftover debug output; drop it (or guard it behind a dev flag) so the modal can open silently.
• Frontend/src/scripts/features/settings.ts:587‑647 – the “Save” button is toggled to the saved state before any async work completes, and the catch block never resets it. If the backend call fails (e.g., plugin settings save throws), the button stays disabled with “Saved!” and the user can’t try again. Move the “Saved” styling/text into the success path (or revert it in finally) so failures don’t permanently lock the control.

opencode session  |  github run

[github-actions]

Plugin APIs

• Backend now speaks to long-lived Node runtimes, exposes runtime metadata (menus/settings) and plugin settings persistence hooks for the front end.
• Settings UI renders plugin menus/settings dynamically, calls the new runtime commands, and keeps the modal state in sync when plugins are toggled.

Issues

• Frontend/src/scripts/features/settings.ts:586-645 – The “Save” button flips into its disabled “Saved!” state as soon as the async TAURI.invoke returns, but nothing clears that state if the backend call fails (see the catch block). After a failure the button stays disabled forever and the user can’t retry. Update the saved-state/text inside the success path (or revert it in a finally) so errors leave the control usable.
• Frontend/src/scripts/features/settings.ts:197-229 – Every time the settings dialog opens you sequentially await TAURI.invoke('get_plugin_settings') for every installed plugin. Each call can spawn a Node runtime if it isn’t already running, so the dialog now starts every enabled plugin one by one and keeps the modal busy until every RPC round-trip completes. On a machine with many plugins this will noticeably stall the UI and spawn dozens of Node processes before the user even interacts. Consider loading plugin settings lazily (e.g., on demand when a panel is activated) or parallelizing/capping these requests so opening the modal no longer forces every plugin to start.

opencode session  |  github run

[github-actions]

Plugin Save Flow

• Frontend/src/scripts/features/settings.ts:664‑715 – flashSavedState (and the “Saved!” styling/text) is triggered immediately after TAURI.invoke('save_plugin_settings')/set_global_settings resolves, but before the backend work actually completes, and there is no reset path in the catch. If any async call later rejects, the save button stays disabled in its “Saved!” state and the user can’t try again. Move the saved-state animation/text into the success path (or revert it in finally) so failed saves keep the control enabled and show the failure message instead of a permanent “Saved!” lock.

Plugin Removal Menu Refresh

• Frontend/src/scripts/features/settings.ts:1755‑1791 – when the user removes a plugin via the context menu, the code updates the installed list and persists the disabled/enabled sets but never re-renders the plugin menus/panels. The removed plugin still appears in the sidebar and its panel is still selectable, so clicking it now races against a non-existent runtime (and still schedules ensurePluginSettingsLoaded). Call renderPluginMenus(modal) (and re-activate the current section) after uninstalling so the nav/panels drop the removed plugin and don’t try to interact with it anymore.

opencode session  |  github run

[github-actions]

Review

• Backend/src/plugin_runtime/node_instance.rs:93-126 – NodeRpcProcess::call keeps calling recv_timeout(timeout) inside the loop without tracking how much of the 30 s/60 s budget has already elapsed. A noisy plugin that streams notifications but never emits the matching response can therefore reset the timer on every notification and leave the host stuck waiting forever for a response, which freezes the UI. Use an Instant deadline (or subtract the elapsed time from timeout) so notifications can’t indefinitely postpone the timeout, and fail back when the overall window expires.

• Frontend/src/scripts/features/settings.ts:1632-1645 – There’s a console.log inside persistSinglePluginToggle that fires every time a plugin is toggled. This leaks low-value debug noise into the production console and duplicates the notification that already runs via notify. Consider removing it or routing it through console.debug/the logging system so the settings modal can operate silently in release builds.

opencode session  |  github run

[github-actions]

• In Frontend/src/scripts/features/settings.ts:664-721, the save button is pushed into its disabled “Saved!” state immediately after TAURI.invoke resolves but before we know if the backend work finished, and the catch branch never reverses that state. If saving fails (e.g., save_plugin_settings rejects) the button stays disabled forever with “Saved!” and the user can no longer retry. Move flashSavedState (and any text updates) into the success path or reset the button in finally so failures leave the control enabled and still show the error notification.
• Opening the settings modal currently fires get_plugin_settings for every installed plugin in sequence (Frontend/src/scripts/features/settings.ts:197-229) which, for each disabled plugin, will start a runtime even if it shouldn’t and will block the modal until all RPCs return. That makes the dialog sluggish on machines with many plugins. Consider loading plugin settings on demand (e.g., when the panel is activated) or batching/parallelizing these invocations so the modal no longer spins up every runtime on open.
• Backend/src/plugin_runtime/node_instance.rs:93-127 keeps calling recv_timeout(timeout) in a loop with the same timeout value, so each notification resets the timer and the host can wait forever if a plugin sends frequent notifications and never responds. Track a deadline (e.g., via Instant::now() + timeout) and subtract elapsed time before the next recv_timeout, or break out when the total duration has passed, so notifications can’t indefinitely postpone the RPC timeout.

opencode session  |  github run