Changeset 6248497 in Klonkt for scripts/import-archive.mjs

Timestamp:

08/07/2026 04:37:37 PM (5 weeks ago)

Author:

roboburr <roboburr@…>

Branches:

main

Children:

a4fea5e

Parents:

7d7b36d

git-author:

roboburr <roboburr@…> (08/07/2026 04:37:26 PM)

git-committer:

roboburr <roboburr@…> (08/07/2026 04:37:37 PM)

Message:

Export en import kiezen de juiste instance, en tijdstempels zijn echt UTC

Twee fouten, allebei op productie gevonden en allebei van het soort dat SUCCES
meldt.

## 1. Het script opende de verkeerde database

Op een split install deelt elke Klonkt de code in /opt/klonkt maar staat zijn data
onder /var/lib/klonkt/<slug>/ met een eigen .env. De scripts lazen die .env niet,
dus database.js viel terug op storage/database.sqlite IN DE CODE-MAP. Op een
server die ooit de enkelvoudige opzet draaide ligt daar een achtergebleven oude
database.

Waargenomen: export-archive.mjs boiert schreef een archief van 444 bytes met
"posts: 0" en meldde dat het gelukt was, terwijl het in een oude lege database
keek. liz en sood gaven "onbekende site". Het script raakte die oude database
ook nog aan (boot-migraties), terwijl het alleen hoort te lezen.

Nu leest scripts/instance-env.mjs de .env van de instance (standaard
/var/lib/klonkt/<slug>/.env, of --data-root / --env) VOORDAT de service geladen
wordt -- database.js opent de database namelijk bij import. De uitvoer noemt
voortaan welke .env en welke database gebruikt zijn.

En zonder PUBLIC_BASE_URL stopt hij nu HARD in plaats van het als bijzin te
melden: zonder origin krijgt het archief een lege origin, en dan maakt een import
nieuwe AP-ids. Dan is het een kopie van de tekst en geen herstel -- precies de
belofte waar het formaat om draait.

Voor de importer weegt dit zwaarder dan voor de exporter: in de verkeerde
database schrijven draai je niet terug.

## 2. Tijdstempels schoven met de tijdzone van de machine

Vraag van Bart: normaliseert de export wel naar UTC? Nee.

SQLite schrijft CURRENT_TIMESTAMP als "2026-07-01 12:56:10" -- in UTC, maar zonder
zone. Date.parse leest die vorm als LOKALE tijd. Op een machine in Amsterdam komt
daar 10:56:10Z uit: twee uur verschoven, in elk archief.

Geen enkele test kon dat zien, want de testmachine draait op UTC. En mijn eigen
rondgang-vergelijking plakte er zelf een Z achter, waarmee ik er precies overheen
keek.

toISO leest een zoneloze vorm nu expliciet als UTC. Nieuwe test die alleen onder
een niet-UTC zone iets bewijst; gecontroleerd dat hij onder Europe/Amsterdam
omvalt zonder de fix. Hele suite 577/577 onder zowel UTC als Europe/Amsterdam.

File:

• scripts/import-archive.mjs (modified) (2 diffs)

scripts/import-archive.mjs

@@ -17 +17 @@
 // en hoort een aparte, bewuste actie te zijn.
 
-import { readArchive, importArchive } from '../src/services/ArchiveImportService.js';
+import { kiesInstance, eisOrigin } from './instance-env.mjs';
 
 const args = process.argv.slice(2);
@@ -24 +24 @@
 
 if (!slug || !bron) {
-  console.error('gebruik: node scripts/import-archive.mjs <slug> <archief.zip|map> [--dry-run] [--overwrite]');
+  console.error('gebruik: node scripts/import-archive.mjs <slug> <archief.zip|map> [--data-root <map>] [--env <pad>] [--dry-run] [--overwrite]');
   process.exit(1);
 }
+
+// EERST de instance kiezen, DAN pas de service laden -- database.js opent de
+// database bij import. Bij een IMPORT weegt dit zwaarder dan bij een export: in
+// de verkeerde database schrijven is niet terug te draaien.
+const vlag = (naam) => { const i = args.indexOf(naam); return i >= 0 ? (args[i + 1] || null) : null; };
+let gekozen;
+try {
+  gekozen = kiesInstance(slug, { dataRoot: vlag('--data-root'), envPad: vlag('--env') });
+} catch (e) { console.error(e.message); process.exit(1); }
+eisOrigin(gekozen.bron);
+console.log(`instellingen uit: ${gekozen.bron || 'de omgeving'}`);
+console.log(`database        : ${process.env.DATABASE_PATH || '(standaard in de code-map)'}`);
+
+const { readArchive, importArchive } = await import('../src/services/ArchiveImportService.js');
 
 let files;