officerdev/platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

plugins: enabling pulls first, so a plugin off for a week comes back current

Browse Source 
A disabled plugin keeps its directory, and the directory is what the next start runs. The longer it
stays off the more certainly it is stale, and enabling would quietly run whatever was current on the
day it was switched off — with every step reporting success, which is exactly how the jellyfin
install on alpha re-applied a two-day-old checkout.

Deleting no longer has that problem, since it takes the directory with it and installing is always a
fresh clone. That left disable/enable as the one remaining way to run old code without being told.

The pull is best-effort and the enable is not. `updatePlugin` returns ok:false when a pull is
refused, and it is refused for reasons that say nothing about whether the plugin can run: a dirty
working tree — every plugin directory on this machine is one — an unreachable forge, or a directory
copied in rather than cloned. Enable is the reversible half of a pair with disable, and a switch that
will not turn back on because a network is down is worse than one running last week's code. So the
refresh reports which of those happened and the enable proceeds regardless; a re-apply that fails
falls back to the code already on disk, which was running before it was disabled.

Tested by the refusal path rather than the happy one: a directory that is not a checkout comes back
having reported "not refreshed", and the error that surfaces is about not being installed rather than
about git — which is only possible if the refusal was stepped past instead of returned.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
pastilhas
2026-08-20 21:34:38 +00:00
co-authored by Claude Opus 5
parent 287cec39d0
commit 16dd67a3ca
4 changed files with 91 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/servers/api/plugins/router.ts
+5 -3
View File
@@ -14,7 +14,7 @@ import {
purgePlugin,
type PluginActionResult,
} from '../../plugins/install';
import { updatePlugin, syncCapabilities } from '../../plugins/update';
import { updatePlugin, enablePlugin, syncCapabilities } from '../../plugins/update';
// /api/plugins — what is on this machine, what is installed, and the four verbs that change it.
//
@@ -233,8 +233,10 @@ pluginsRouter.post('/:appName/purge', async (ctx) => {
return ctx.json(await purgePlugin(ctx.req.param('appName'), { dropData: true }));
});
// Enabling refreshes the checkout first — see `enablePlugin`. A disabled plugin's directory is what the
// next start runs, so turning one back on used to run whatever was current the day it was switched off.
pluginsRouter.post('/:appName/enable', async (ctx) => {
const result = await setPluginRunning(ctx.req.param('appName'), true);
const result = await enablePlugin(ctx.req.param('appName'), undefined, ctx.get('user').id);
return ctx.json(result, result.ok ? 200 : 400);
});
@@ -265,7 +267,7 @@ type VerbFn = (
const VERBS = {
install: (appName, onStep, userId, onLog) => installPlugin(appName, onStep, userId, onLog),
enable: (appName, onStep) => setPluginRunning(appName, true, onStep),
enable: (appName, onStep, userId, onLog) => enablePlugin(appName, onStep, userId, onLog),
disable: (appName, onStep) => setPluginRunning(appName, false, onStep),
// Same function, and the verb IS the flag — see the two routes above.
delete: (appName, onStep, _userId, onLog) => purgePlugin(appName, { dropData: false }, onStep, onLog),