You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(binkp): apply config.hjson reloads without a restart (#721)
config.hjson is watched and reloaded at runtime, but the BinkP module read
most of its configuration once during startup and threaded the values into
long-lived closures. The inbound listener in particular captured a BsoSpool,
the local address list, and the whole binkp config block, then reused them
for every connection for the life of the process. After a reload, inbound
sessions kept resolving outbound directories against the old paths and
networks, advertised the old local addresses, and authenticated against the
old node passwords -- silently, until the BBS was restarted. The pull cycle
dialed the node set as it was at boot, and the crashmail debounce window was
fixed at its startup value.
Nothing here needed a new mechanism: binkp.js binds Config as a call-time
indirection already, so the fix is to stop reading early.
* _handleConnection() resolves the spool, local addresses, node/FREQ
config, and tempDir per connection -- once at the top, so values can't
shift mid-session. Both listeners now close over nothing but `this`.
* _pullAddresses() defaults to the live config; the parameter stays for
callers evaluating some other node set.
* the crashmail debounce window is read per burst.
Two things can't be fixed by reading later, and are reconciled on the
ConfigChanged event instead:
* pullSchedule is compiled into a later.js timer, so the timer is rebuilt
when the expression changes (and cleared when it is removed).
* the inbound listener bindings -- enabled, port, address, tls.* -- are
baked into a socket at listen() time. Rebinding under live sessions is
not something a reload should do, so a change to those keys is reported
as restart-required rather than silently ignored.
Also consolidates the three near-identical BsoSpool constructions into a
single buildSpool() in binkp/util.js, whose header already asked for exactly
that ("...so the three callsites can't drift").
Copy file name to clipboardExpand all lines: docs/_docs/messageareas/binkp.md
+20Lines changed: 20 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -242,6 +242,26 @@ freq: {
242
242
243
243
With this setup, every new nodelist that arrives via TIC is immediately FREQ-serveable — no path configuration to maintain.
244
244
245
+
#### Reloading configuration
246
+
247
+
`config.hjson` is watched and reloaded while the BBS runs. Almost everything under `binkp` is read at the moment it is used, so a reload applies on its own:
248
+
249
+
| Setting | Applies to | When it takes effect |
250
+
|---------|-----------|----------------------|
251
+
|`nodes` (hosts, ports, passwords, `pull`, TLS) | next session, inbound or outbound | Immediately |
252
+
|`freq`| next inbound session | Immediately |
253
+
|`crashmailDebounceMs`| next crashmail burst | Immediately |
254
+
|`tempDir`, `staleLockMaxAgeMs`| next session | Immediately |
255
+
|`ftn_bso``paths` and `messageNetworks.ftn.networks`| next session or poll | Immediately |
256
+
|`pullSchedule`| the pull timer | On reload — the timer is rebuilt |
257
+
|`inbound.enabled`, `inbound.port`, `inbound.address`, `inbound.tls.*`| the listening socket |**Restart required**|
258
+
259
+
The last row is bound into the socket when it starts listening; changing it under live sessions is not something a reload can do safely. A reload that touches those keys logs a warning naming them so the change isn't silently lost:
260
+
261
+
```
262
+
[BinkP] Inbound listener settings changed; restart required for them to take effect
0 commit comments