Plugin settings saved from Settings UI don't take effect until app restart

[bsnelson]

Summary

Changing a plugin setting from the in-app Settings screen (e.g. enabling "Upload shots automatically" on shot-upload.reaplugin) persists the new value to disk, but the already-running plugin instance never picks it up. The setting shows as enabled everywhere you'd check it, but nothing actually happens until the plugin is reloaded (app restart, or a manual disable/enable).

Repro

1. Enable AutoUpload for shot-upload.reaplugin via the app's plugin settings screen (Save).
2. Without restarting the app, pull one or more shots.
3. Observe: no upload happens, and no [shot-upload] log line is written at all (not even a "skipped" line — the shotStored handler's if (state.autoUpload) gate is silently false).

Confirmed on a live 0.8.0 device:

GET /api/v1/plugins/shot-upload.reaplugin/settings  ->  {"AutoUpload": true}   (persisted)
GET /api/v1/plugins/shot-upload.reaplugin/status    ->  {"autoUpload": false}  (live plugin state)

The log showed the plugin had not reloaded since the prior app boot, well before the setting was changed.

Root cause

• The in-app Settings screen (lib/src/settings/plugins_settings_view.dart, Save button handler) calls PluginLoaderService.savePluginSettings(pluginId, outgoing) directly.
• PluginLoaderService.savePluginSettings (lib/src/plugins/plugin_loader_service.dart) only writes the new settings to storage — it never reloads the plugin or emits a settingsUpdated event to the running instance.
• Compare this to POST /api/v1/plugins/<id>/settings (lib/src/services/webserver/plugins_handler.dart:_handlePluginSettingsPost), which calls savePluginSettings and then reloadPlugin(id) — so changing a setting via the REST API takes effect immediately, but changing it via the app's own Settings UI does not.

Impact

Any plugin whose behavior depends on a settings toggle (not just shot-upload.reaplugin) is affected: the UI implies the change is live, but stale in-memory state silently persists until the next app restart or a manual plugin disable/enable. For shot-upload.reaplugin specifically, this means a user can enable AutoUpload (or, as of the DrainHistory backlog-drain feature, DrainHistory) and see nothing happen, with zero error surfaced anywhere.

Related/compounding: plugin host.log() output is logged at Logger.finest severity (plugin_manager.dart, _handleMessageSafely), while the app's default log level is INFO. So even on a build where the bug above doesn't apply, plugin log lines (upload success/failure/skip) are invisible unless the log level is manually raised to FINEST first. Worth considering whether plugin logs should default to a more visible level, or whether the in-app log viewer should offer an easy way to include them.

Suggested fix

Make PluginLoaderService.savePluginSettings (or its caller in plugins_settings_view.dart) trigger the same live-reload path the REST endpoint already uses, so both code paths behave consistently.

---

Filed by Claude on behalf of a user who lost a settings toggle to this on 0.8.0; verified the fix has not landed as of the 0.8.1 release (compared plugins_settings_view.dart / plugin_loader_service.dart between v0.8.0 and v0.8.1 — no changes to the save/reload path).

[bsnelson]

Follow-up: drain doesn't retry when the machine reconnects at boot

Verified on a live 0.8.1 device after the settings/reload issue above was worked around by a full app restart:

• Switches (AutoUpload, DrainHistory) came up correctly on this boot — persisted settings and live plugin state agreed (GET /plugins/shot-upload.reaplugin/status matched /settings).
• But the backlog drain never actually started on its own: drainRunning: false, all counters at 0, drainLastRunAt: null.
• Root cause: shot-upload.reaplugin's onLoad calls startDrain("load") once, which bails out early if fetchLocal("/machine/info") has no serialNumber yet (log("drain skipped: no machine connected"); return;). At app boot the plugin loads before the DE1 finishes reconnecting over BLE, so this one attempt fails and is never retried — startDrain is otherwise only called from the shotStored and settingsUpdated (drainHistory turned on) event handlers, neither of which fires just because a machine connects later.
• Confirmed manually: POST /api/v1/plugins/shot-upload.reaplugin/drain immediately started a successful drain (2000+ shots scanned, uploads succeeding) once the machine was actually connected — so the drain logic itself is fine, it's purely the boot-time retry gap.

Suggested fix: have the plugin also attempt startDrain("machineConnected") when it observes the machine transition into a connected/idle state (if events.machine/stateUpdate is available to it), or have PluginManager/onLoad retry the initial drain attempt a few times with backoff instead of a single fire-and-forget try.

Not blocking — a manual POST .../drain (or waiting for the next real shot to fire shotStored) works around it — but worth fixing so DrainHistory reliably self-starts after every app restart, per the plugin's own intent.

[tadelv]

thanks @bsnelson , I moved the follow up into a separate issue. Agreed on the auto-reload when native plugin settings are saved

[tadelv]

@bsnelson can you re-test if the drain issue has been fixed? Should be ok with 0.8.2