Let the server apply saved settings, and reload only for older servers #16

Merged

jcoffey-dev merged 1 commits from feature/server-settings-reload into main

2026-09-24 20:13:16 +00:00

jcoffey-dev commented

2026-09-24 20:07:10 +00:00

Owner

Follow-up to #15. inbuxa-server now reloads the running settings itself after an x:<Object>/set (server PR #39) and reports it in the set response. This makes the admin's own reload a fallback for servers that don't.

What the server sends

x:settingsReload is a top-level argument of the x:<Object>/set response, next to created/updated/destroyed, one per method response (not per created id):

{"applied": true}
{"applied": false, "description": "Saved, but the running settings were not reloaded. <Type> with id <id>: <error>"}
absent when the write changed nothing or needs no reload

Targeted reloads (certificates, lookup stores, blocked/allowed IPs) report through the same field.

Behavior

Field present: the admin sends nothing for that write.
- applied: true gives the existing "Saved and applied" toast, still one per burst of saves.
- applied: false gives the existing banner with the server's reason. The lead-in the banner already says is dropped, and the named object is linked. "Apply now" sends ReloadSettings as before.
- A later write the server applies clears an earlier refusal.
Field absent, type needs a reload (older server): the admin queues its own reload as before.
Field absent, type needs none: nothing happens, as before.
Mixed burst: if the admin had to send a reload, its result decides the burst. Otherwise the server's reports decide it. A reload the server applied after an earlier queued one of the same kind removes the queued one. A reload queued after it is still sent.
A known refusal is not retried on unrelated saves, as with a failed admin reload.
Directory and Authentication writes, which the admin table treats as needing nothing, keep their form's own "Saved successfully" toast when the server applies them. A refusal still shows the banner.

Table vs. server #39

The admin table now matches the server's list, with one exception:

Admin reloaded, server doesn't. Changed here to "none": Alert, DnsServer, Enterprise and SpamLlm are read from the registry when used. MetricsStore and TracingStore are stores opened at startup.
Server reloads, admin table says none: Directory and Authentication. These are unchanged. Older servers reload them on write without reporting it, and newer ones report it.
Disagreement kept: AllowedIp. The server maps it to the targeted blocked-IP reload, which only rebuilds the blocked list. Allowed addresses are part of the full settings and only rebuilt by a full reload. So a newer server reports applied: true while the change isn't live. The admin keeps ReloadSettings for AllowedIp and ignores the report for that type. The server should map AllowedIp to a full reload. Once it does, the exception can go.

Strings

New: settingsApply.notReloaded ("The server did not reload its settings."), used only when a refusal comes without a description. English is the only catalogue.

Checks

npm run typecheck, npm run lint, npm test (371 tests) and npm run build pass locally. New tests cover:

a newer server: applied, refused, refused then applied, a refusal cleared later, no retry on unrelated saves, AllowedIp
an older server: the existing cases
mixed bursts: one result, a queued reload not taken back, the admin reload settling a server refusal, a report landing while a reload is out

Follow-up to #15. **inbuxa-server** now reloads the running settings itself after an `x:<Object>/set` (server PR #39) and reports it in the set response. This makes the admin's own reload a fallback for servers that don't. ## What the server sends `x:settingsReload` is a top-level argument of the `x:<Object>/set` response, next to `created`/`updated`/`destroyed`, one per method response (not per created id): - `{"applied": true}` - `{"applied": false, "description": "Saved, but the running settings were not reloaded. <Type> with id <id>: <error>"}` - absent when the write changed nothing or needs no reload Targeted reloads (certificates, lookup stores, blocked/allowed IPs) report through the same field. ## Behavior - **Field present:** the admin sends nothing for that write. - `applied: true` gives the existing "Saved and applied" toast, still one per burst of saves. - `applied: false` gives the existing banner with the server's reason. The lead-in the banner already says is dropped, and the named object is linked. "Apply now" sends ReloadSettings as before. - A later write the server applies clears an earlier refusal. - **Field absent, type needs a reload (older server):** the admin queues its own reload as before. - **Field absent, type needs none:** nothing happens, as before. - **Mixed burst:** if the admin had to send a reload, its result decides the burst. Otherwise the server's reports decide it. A reload the server applied after an earlier queued one of the same kind removes the queued one. A reload queued after it is still sent. - A known refusal is not retried on unrelated saves, as with a failed admin reload. - Directory and Authentication writes, which the admin table treats as needing nothing, keep their form's own "Saved successfully" toast when the server applies them. A refusal still shows the banner. ## Table vs. server #39 The admin table now matches the server's list, with one exception: - **Admin reloaded, server doesn't. Changed here to "none":** Alert, DnsServer, Enterprise and SpamLlm are read from the registry when used. MetricsStore and TracingStore are stores opened at startup. - **Server reloads, admin table says none:** Directory and Authentication. These are unchanged. Older servers reload them on write without reporting it, and newer ones report it. - **Disagreement kept: AllowedIp.** The server maps it to the targeted blocked-IP reload, which only rebuilds the blocked list. Allowed addresses are part of the full settings and only rebuilt by a full reload. So a newer server reports `applied: true` while the change isn't live. The admin keeps ReloadSettings for AllowedIp and ignores the report for that type. The server should map AllowedIp to a full reload. Once it does, the exception can go. ## Strings New: `settingsApply.notReloaded` ("The server did not reload its settings."), used only when a refusal comes without a description. English is the only catalogue. ## Checks `npm run typecheck`, `npm run lint`, `npm test` (371 tests) and `npm run build` pass locally. New tests cover: - a newer server: applied, refused, refused then applied, a refusal cleared later, no retry on unrelated saves, AllowedIp - an older server: the existing cases - mixed bursts: one result, a queued reload not taken back, the admin reload settling a server refusal, a report landing while a reload is out

jcoffey-dev added 1 commit 2026-09-24 20:07:10 +00:00

Let the server's own settings reload stand, and reload only for older servers

ci / build (pull_request) Successful in 57s

Details

ci / publish (pull_request) Skipped

Details

cf6047eb8b

The server now applies a registry write to the running settings itself and
says how it went in the set response: a top-level "x:settingsReload" of
{"applied": true} or {"applied": false, "description": "Saved, but the
running settings were not reloaded. <object>: <error>"}, absent when the
write needs no reload. Sending ReloadSettings after it is a second reload
per burst of saves, and a refused one only repeats what the server said.

The JMAP client now hands the listener each written type with the server's
report, when there is one. A write that carries it queues nothing: applied
removes that reload from what's pending (the server's reload came after
every earlier write of that kind), and a refusal queues it as known
unapplied, as a failed reload from the admin would, without sending it.
A write without the report is an older server's, and queues the admin's
reload as before. When the burst settles there is still one result: the
admin's reload decides it when it had to send one; otherwise a "Saved and
applied" toast, or the banner with the server's reason and the object it
named, and "Apply now" sending ReloadSettings. A later write the server
applies clears an earlier refusal.

"Saved and applied" stays for settings objects; a directory or the default
authentication, which the server also reloads, keeps its form's own toast.

The type table follows the server's list of what each write needs. Alert,
DnsServer, Enterprise and SpamLlm are read when used, and MetricsStore and
TracingStore are stores, so they need no reload; the admin sent one for
each. Allowed IPs are part of the full settings, but the server answers an
AllowedIp write with the blocked-IP reload, which doesn't rebuild them, so
for those the admin still sends ReloadSettings whatever the report says.

New string, in src/i18n/en.json (the only catalogue) under settingsApply:
notReloaded, shown when a refusal comes without a description.

jcoffey-dev merged commit eb1c3c8b0e into main

2026-09-24 20:13:16 +00:00

jcoffey-dev deleted branch feature/server-settings-reload

2026-09-24 20:14:44 +00:00

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: inbuxa/inbuxa-admin#16