fix: show progress when saving plugin config

[backrooms-yrc]

Motivation

Plugin configuration saves can take a noticeable amount of time while the config is persisted and the plugin is reloaded. Previously, the dashboard provided no in-progress feedback, which could make the interface appear frozen or unresponsive (issue #9323).

Changes

• Display the existing loading dialog before submitting plugin configuration changes.
• Show a success result after a successful save, then close the configuration dialog.
• Keep the configuration dialog and entered values when the API reports an error or the request fails, so users can review and retry.

Breaking Changes

• No breaking changes.

Verification

• Dashboard built successfully with the updated source.
• Verified the running WebUI now shows a progress dialog when clicking "Save and Close".

Checklist

• The change is scoped to the plugin configuration save flow.
• No new dependencies were added.
• No malicious code was introduced.

Summary by Sourcery

Improve user feedback during plugin configuration saves in the dashboard.

Enhancements:

• Show a loading dialog while plugin configuration changes are being saved.
• Report success via the loading dialog and close the configuration dialog on successful saves.
• Preserve the configuration dialog and surface detailed errors in the loading dialog when the save fails.

[gemini-code-assist]

Code Review

This pull request updates the updateConfig function in useExtensionPage.js to manage a loading dialog state during the configuration update process. It initializes the loading dialog before the API call and updates its status based on the success or failure of the request. A review comment suggests using the resolveErrorMessage helper to extract a user-friendly error message instead of passing the raw error object to toast and onLoadingDialogResult.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Passing the raw err object directly to toast can result in displaying [object Object] or unhelpful error details to the user. We should use the existing resolveErrorMessage helper to extract a user-friendly error message, and use it consistently for both the toast and the loading dialog.

      const errMsg = resolveErrorMessage(err, tm("messages.operationFailed"));
      toast(errMsg, "error");
      onLoadingDialogResult(2, errMsg, -1);

[backrooms-yrc]

Thanks for the catch! Addressed in commit 4fa35d7: the catch block now uses resolveErrorMessage(err, tm("messages.operationFailed")) and reuses the normalized message for both toast and onLoadingDialogResult, consistent with how other actions in this file handle errors (e.g. reloadPlugin).

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• In the catch block and non-ok response branch, consider normalizing the error passed to toast (e.g., err.message || String(err) / String(res.data.message)) to avoid relying on implicit object-to-string conversion and ensure consistent user-facing messages.
• The loading dialog is initialized inline in updateConfig; if other actions use similar progress flows, consider extracting a small helper to set loadingDialog defaults to keep the behavior consistent and reduce duplication.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the catch block and non-`ok` response branch, consider normalizing the error passed to `toast` (e.g., `err.message || String(err)` / `String(res.data.message)`) to avoid relying on implicit object-to-string conversion and ensure consistent user-facing messages.
- The loading dialog is initialized inline in `updateConfig`; if other actions use similar progress flows, consider extracting a small helper to set `loadingDialog` defaults to keep the behavior consistent and reduce duplication.

## Individual Comments

### Comment 1
<location path="dashboard/src/views/extension/useExtensionPage.js" line_range="1069-1071" />
<code_context>
       extension_config.metadata = {};
       extension_config.config = {};
       getExtensions();
     } catch (err) {
       toast(err, "error");
+      onLoadingDialogResult(2, err.message || String(err), -1);
     }
   };
</code_context>
<issue_to_address>
**issue (bug_risk):** Align the error message used for `toast` with the one passed to `onLoadingDialogResult` to avoid non-string toasts.

In the `catch` block, `toast(err, "error")` can show `[object Object]` when `err` isn’t a string, while `onLoadingDialogResult` already normalizes the error. Please reuse the same normalized message for both, e.g.:

```ts
} catch (err) {
  const msg = err.message || String(err);
  toast(msg, "error");
  onLoadingDialogResult(2, msg, -1);
}
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}