sql: re-seed lookup rows on upgrade

[aberoham]

A database created by 2.x has the nameserver export types and record types of its day; nothing in sql/upgrade added the ones v3 introduced, so an upgraded install can't create a coredns or native nameserver (lib/nameserver/test/runtime.js fails with unknown nameserver type: native on such a database). Found by running a 2.41 production dump through the upgrade path; with this file applied that database passes the runtime tests. INSERT IGNORE keeps an operator's own row under a clashing id; the header says how to check.

[msimerson]

# Safe to re-run: INSERT IGNORE keeps
# existing rows. That also means a row you added yourself under one of
# these ids keeps its name and the v3 type it shadows stays unavailable;
# check with
#   SELECT id, name FROM nt_nameserver_export_type WHERE id >= 9;
# and renumber yours first if it clashes.

That sounds like really dangerous advice:

 NicTool/server/sql ➜ grep nt_nameserver_id *                            on  master [$!] via 🐪 v5.40.4 
04_nt_nameserver.sql:    nt_nameserver_id    SMALLINT UNSIGNED AUTO_INCREMENT NOT NULL,
04_nt_nameserver.sql:    PRIMARY KEY (`nt_nameserver_id`),
04_nt_nameserver.sql:    KEY `nt_nameserver_idx1` (`name`),
04_nt_nameserver.sql:    KEY `nt_nameserver_idx2` (`deleted`),
04_nt_nameserver.sql:    nt_nameserver_id    SMALLINT UNSIGNED NOT NULL,
04_nt_nameserver.sql:    KEY `nt_nameserver_log_idx1` (`nt_nameserver_id`),
04_nt_nameserver.sql:INSERT INTO nt_nameserver_log(nt_group_id,nt_user_id, action, timestamp, nt_nameserver_id) VALUES (1,1,'added',UNIX_TIMESTAMP(), 1);
04_nt_nameserver.sql:INSERT INTO nt_nameserver_log(nt_group_id,nt_user_id, action, timestamp, nt_nameserver_id) VALUES (1,1,'added',UNIX_TIMESTAMP(), 2);
04_nt_nameserver.sql:INSERT INTO nt_nameserver_log(nt_group_id,nt_user_id, action, timestamp, nt_nameserver_id) VALUES (1,1,'added',UNIX_TIMESTAMP(), 3);
04_nt_nameserver.sql:    nt_nameserver_id                SMALLINT UNSIGNED NOT NULL,
04_nt_nameserver.sql:    KEY `nt_nameserver_export_log_idx1` (`nt_nameserver_id`)
08_nt_zone.sql:    nt_nameserver_id     smallint(5) unsigned NOT NULL,
08_nt_zone.sql:    UNIQUE KEY `zone_ns_id` (`nt_zone_id`,`nt_nameserver_id`)

[aberoham]

sorry I was having my clanker reason about its wanker move here, add tests to avoid similar facepalm

[aberoham]

The ubuntu-latest, 24 failure isn't from this PR. It only touches sql/, and
the same commit passed test (ubuntu-latest, 22), test-mac, test-win and
test-docker. GET /zone_record paginates has been intermittent since at
least 2026-08-24, which is when the DIAGZR instrumentation went in.

That instrumentation did catch something this run. The three records the test
creates come back with ids from the POST, then aren't in the table:

DIAGZR createdIds= [60002,60003,60211,60212,60213]
DIAGZR all-records-for-zid= [5096, 60002, 60003]

So it isn't the pagination or the search filter — rows that reported
themselves created are absent. I'm digging into that separately. This job
likely just needs a re-run to go green.

[msimerson]

A primary intent of this PR, as stated in the description, is to add coredns and native to the nt_nameserver_export_type table. The problem is, it's not very good at that.

1. Silent no-op on clash. id is AUTO_INCREMENT; a 2.x site that added its own export type got id 9. INSERT IGNORE then skips coredns, the operator sees no error, and the bug the PR fixes stays unfixed. The header says to check by hand. 👎
2. Duplicate names are possible. nt_nameserver_export_type has only PRIMARY KEY (id) — no unique index on name. A site that already added coredns at id 11 ends up with two rows named coredns.
3. The resource_record_type block is a no-op on 2.41. Legacy NicTool/server/sql/06_resource_records.sql seeds the identical 28 rows with identical ids, and upgrade.pl:180 already restores them for pre-2.18 databases. Harmless, but only the two nameserver rows (9, 10) actually do anything.

[aberoham]

Fixed in da19535. The migration now adds missing nameserver types by name and lets the table assign their ids. Existing custom rows and existing names are unchanged. The record-type reseed is gone. Tests cover id clashes, duplicate names, and repeat runs.

[msimerson]

I think your agents are getting dumber. Or ... clumsier? That's the least elegant SQL I've seen in quite a while, and the tests are ... nearly as clumsy. You're not testing the infinite monkey theorem are you?

[msimerson]

consider #72 as a less clumsy alternative.

[aberoham]

I deffo drove off the cliff into roadrunner land with Ox Alpha (GLM-5.3 Flash) and need to give the harness a good scrub, alongside a better adversarial review loop that's custom-tuned rather than simply "when done, throw it over to another model."

I've created a corpus tool + anonymised DB snapshot out of a few old database backups I have laying around, imagine getting going and starting to solicit for other "as live" donor DBs may help tighten it up.

And then I wonder about backfilling some of the Greg Schueler style extended tests in areas of v2 that evolved after the initial cut of v2.01.

[msimerson]

Yeah, the harness could do with a simplicity and performance refactor.

[msimerson]

the Claude /code-review skill is NOT fast but is pretty good. Copilot's code review is pretty good too.