E2E: fetching a Regulation by business slug answers 500, deterministically

[rubenvdlinde]

tests/e2e/visual/pages.visual.spec.ts:367 (gate-26 — every page component renders its own screen › Regulation detail, resolved by business slug) fails on
development:

Error fetching learniq-Regulation/AVG: 500 Internal Server Error
{status: 500, message: An unexpected server error occurred., details: null}

It is deterministic, not a flake

Two independent runs, same error:

run	result
34448499177 (07:08)	470 passed, 0 failed
34468461118 (10:54)	469 passed, 1 failed
34468461118 re-run (14:43)	469 passed, 1 failed, same 500

I called it a flake after the first failure and re-ran it. It reproduced. It is
real.

What changed, and what did not

learniq's own tree changed by one commit in that window, and it was a version
bump (chore(release): 0.3.2-unstable.20260910105148, #846). A version number
cannot make an object fetch return 500.

What did change is openregister, which this suite installs at development
(additional-apps: [{"repo":"ConductionNL/openregister","ref":"development"}]).
Between 07:08 and 10:54 that branch took roughly a dozen commits, including
#3571 "resolve a register by any slug it has answered to" at 09:14 — which
touches register-slug resolution, and this test fetches by business slug.

⚠️ I could not prove #3571 is the cause and am not claiming it. I read
RegisterSlugResolver and it contains no throw, so the 500 is not obviously
its doing. The window and the subject matter line up; that is all.

What would settle it

Pin openregister to a ref from before 09:14 for one run. If the test passes,
the cause is in that window; if it still 500s, it is learniq's own.

The server-side stack trace behind the 500 would name it outright — the browser
only sees the status.

[github-actions]

Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.

What happens next:

1. A maintainer will review this issue and determine the appropriate action
2. If accepted, it may be converted into an OpenSpec change for structured development
3. You will be notified of any status changes

Triage labels:

• triage:accept-feature — accepted as a new feature
• triage:accept-bugfix — accepted as a bug fix
• triage:needs-info — more information needed
• triage:wontfix — will not be addressed
• triage:duplicate — duplicate of another issue

[rubenvdlinde]

Correction: this is not openregister, and #3571 is excluded

My earlier note pointed at openregister#3571 (resolve a register by any slug it has answered to). That was speculation and it is wrong. #3571 adds RegisterSlugResolver and wires it as a shared service, but nothing on the object read path calls it, and it contains no throw. It is excluded.

The cause is in learniq's own e2e seeder, and #848 addresses it.

What the 500 is

GET /api/objects/learniq/regulation/AVG resolves an identifier against the magic table for that register and schema. The where clause matches only the metadata columns _id, _uuid, _slug and _uri (openregister lib/Db/MagicMapper.php, findInRegisterSchemaTable region, roughly lines 5381 to 5400). When more than one row matches, MagicMapper::findInRegisterSchemaTable raises MultipleObjectsReturnedException at line 5435, which the controller does not catch, so the endpoint answers a bare 500. The stack in the server log lands on exactly that line, so the ambiguity is established, not inferred.

Review of #848

Behaviourally it is safe and it cannot regress anything else. Checked:

• The new branch is gated on markerField === 'slug', and exactly one of the 50 seed() calls uses that marker: the for (const slug of ['AVG', 'NIS2']) regulation loop at line 977. The other 49 keep the old return null on a miss, byte for byte.
• Nothing reads created['regulation']. The only created[...] lookup in the file is created['learner-profile'], so the { ambiguous: true } sentinel never reaches id() and never becomes a foreign key.
• counts['regulation'] still lands on 2 whichever way the probe answers, and writeSeededManifest only gates on count > 0, so .e2e-state/seeded-schemas.json, the MIN_SEEDED_SCHEMAS floor in ci-seed.sh and the row assertions in index-pages.spec.ts all see the same thing as today.
• No spec names AVG (demo). The only spec that touches the record is pages.visual.spec.ts:367, which asserts that /compliance/regulations/AVG resolves to something other than the not-found subtree. It does not say which record, so the imported AVG / GDPR satisfies it as well as the seeded copy would.
• Worst case the probe 404s, the seeder creates as before, and the run behaves exactly as it does now. There is no path where the change makes the failure worse.

One caveat for whoever reads the green

I could not confirm the mechanism the PR body states, and there is a specific reason to doubt it.

SaveObject::setSelfMetadata (openregister lib/Service/Object/SaveObject.php:4055) sets the slug as $selfData['slug'] ?? $data['slug']. The register import passes the object with its @self block intact, so object 12 should land with _slug set to reg-avg, not AVG, and should therefore not answer to the identifier AVG at all. If that reading holds, the new probe returns 404, the seeder creates AVG (demo) exactly as before, and the run goes green for a reason other than the one the PR gives.

Two rows did match AVG in the log, so a second source exists that I could not name from a static read. I excluded the obvious candidates: both import paths (SettingsService::importRegisterConfiguration and the seeder's own importRegister) read the same learniq_register.json through the same components.objects loop, which dedupes on @self.slug and so cannot produce two rows; the x-openregister-seed block on the Regulation schema is empty; learniq_mock_register.json carries no regulation objects; and global-setup.ts skips its seed when ci-seed.sh has written .e2e-state/ci-seeded, so the seeder runs once per job.

So: merge #848, it is safe. But when it goes green, read the seeder log rather than the tick. If it does not show the identifier probe matching, the duplicate is still being created and the green is coincidental.

Separately, the bare 500 is worth an openregister issue on its own. MultipleObjectsReturnedException is a knowable condition and An unexpected server error occurred. Please try again. is advice the caller cannot act on, since retrying cannot help and nothing names the collision.