Found reviewing #811's merged change (ca79f53).
What happens
configure.py's new services-host step shows the first configured host as the prompt's default and, on a blank answer, keeps it - but always writes one entry:
default_host = (current_hostmasks[0].rsplit("@", 1)[-1] ...)
admin_host = input(f"Your services host (blank to skip){suffix}: ").strip() or default_host
...
if admin_host:
changes["ADMIN_HOSTMASKS"] = [f"*!*@{admin_host}"]So an operator with two hosts configured (home and phone, say) who re-runs configure.py and presses Enter at that prompt has the list collapsed to the first. The second host silently loses admin access to the console and the channel commands. Reproduced through collect_answers() with the existing test_configure harness:
configured before : ['*!*@me.users.undernet.org', '*!*@my-phone.example.net']
written by re-run : ['*!*@me.users.undernet.org']
That breaks _current()'s own stated contract - its value is shown back as the prompt's default "so re-running never silently" changes what is configured.
A smaller oddity in the same step: if the first existing entry is a wildcard pattern (*!*@*.home.net), the default becomes *.home.net, pressing Enter prints "That will not do: '.home.net' has a '' in it" about a value the operator did not type, and a second Enter leaves it unchanged. Not destructive, but confusing.
Fix
- A blank answer leaves
ADMIN_HOSTMASKS exactly as it is - write nothing - rather than rewriting it from the first entry.
- Only a typed host is written. When a list with more than one entry already exists, say what will happen before replacing it (or add the typed host to the list instead - either is defensible; replacing silently is not).
- The default shown should be what is there. For a non-
*!*@host first entry, don't offer it as the default at all, so the validator is never run on the operator's existing value.
- Test: a re-run with two entries and a blank answer writes no
ADMIN_HOSTMASKS.
Found reviewing #811's merged change (ca79f53).
What happens
configure.py's new services-host step shows the first configured host as the prompt's default and, on a blank answer, keeps it - but always writes one entry:So an operator with two hosts configured (home and phone, say) who re-runs
configure.pyand presses Enter at that prompt has the list collapsed to the first. The second host silently loses admin access to the console and the channel commands. Reproduced throughcollect_answers()with the existingtest_configureharness:That breaks
_current()'s own stated contract - its value is shown back as the prompt's default "so re-running never silently" changes what is configured.A smaller oddity in the same step: if the first existing entry is a wildcard pattern (
*!*@*.home.net), the default becomes*.home.net, pressing Enter prints "That will not do: '.home.net' has a '' in it" about a value the operator did not type, and a second Enter leaves it unchanged. Not destructive, but confusing.Fix
ADMIN_HOSTMASKSexactly as it is - write nothing - rather than rewriting it from the first entry.*!*@hostfirst entry, don't offer it as the default at all, so the validator is never run on the operator's existing value.ADMIN_HOSTMASKS.