DossierNote schema 404s at runtime — the learniq register does not resolve during seeding

[rubenvdlinde]

Symptom

One e2e test fails on development after #610 and #618:

✘ PupilDossierTimelineView route resolves the registered component for a given learnerId
  Error: unexpected fatal errors: [PupilDossierTimelineView] loadAll error
         Error: DossierNote fetch failed: 404

Run: 1 failed, 436 passed, 20 skipped.

This failure is intentional and correct

#618 quieted 404s in PortfolioBuilder, PortfolioReviewView and TakeAssessmentView, because for a single-object lookup a 404 genuinely means "this record is not here" — ordinary user input, not a fault.

PupilDossierTimelineView was deliberately excluded, and this is why. Every call in its loadAll() is a list query:

this.fetchSchema('DossierNote',       `learnerId=${id}&_limit=200`)
this.fetchSchema('BehaviourIncident', …)
this.fetchSchema('DossierCheckIn',    …)

A learner with no dossier is an empty result set with HTTP 200. A 404 on a list means the schema itself did not resolve. Rendering that quietly as "no dossier found" would report a broken environment as an empty timeline, so the view stays loud — and the test failing is the view doing its job.

The schema is declared, so this is an environment fault

DossierNote appears 8 times in lib/Settings/learniq_register.json (1.16 MB). It is not a missing declaration.

The e2e server log from CI (nextcloud-log-e2e artifact) shows the seed failing to resolve the register at all:

[RegisterMapper] Register does not exist (or is duplicated) before filters  identifier=learniq
[RegisterMapper] Register not found after filters                          identifier=learniq
[MagicMapper]    Failed to find object in register+schema table
                 tableName=openregister_table_14_20
                 error: relation "oc_openregister_table_14_20" does not exist

schema=20 is Course, confirmed by the adjacent line "Discarding 2 properties the schema Course does not declare … schema=20".

Note the wording: "does not exist (or is duplicated)". The lookup fails for learniq twice during its own app's seeding, and the shard table for at least one schema is consequently never created. Whether the cause is absence or duplication is the open question — the message cannot distinguish them, and neither can I from the log alone.

Why it took a routing fix to become visible

Before #610 every e2e navigation used #/… against a createWebHistory router, so all 43 of them rendered the Dashboard. This test "passed" by asserting innerText('body').length > 0 on a page that was never the one under test. The seeding fault has presumably been present the whole time with nothing able to observe it.

What would close this

Determining whether the learniq register is absent or duplicated at seed time, and why the shard tables for its schemas are not created. That is openregister seeding behaviour rather than anything in these views, which is why this is an issue rather than a patch — I would be guessing at a fix, and a wrong guess here writes a quiet fallback over a real infrastructure fault.

[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]

Narrowed: the register was ABSENT, not duplicated

The open question in the description — absence or duplication — is answerable from the source, and the answer is absence.

RegisterMapper's pre-filter probe caps itself to one row:

// Cap to a single row + deterministic order so duplicate-slug rows from
// env churn cannot raise MultipleObjectsReturnedException out of this
// debug-only probe …
$qbBeforeFilter->orderBy('id', 'ASC');
$qbBeforeFilter->setMaxResults(1);

With setMaxResults(1), findEntity() can never see a second row, so MultipleObjectsReturnedException cannot be raised at that point. The catch listed it anyway and logged "does not exist (or is duplicated)" — naming a possibility the code had already excluded.

So the two log lines mean, unambiguously: the learniq register did not exist when seeding looked for it. Not a duplicate to be merged with openregister:registers:dedupe; genuinely not there yet.

That reframes this issue. It is not a data-cleanup problem, it is an ordering or failure problem in register creation during seed — the register is looked up before whatever creates it has succeeded, or that creation failed silently earlier in the run.

The misleading message is fixed in ConductionNL/openregister#2871, so the next occurrence will say which it was rather than hedging.

Still open here, and unchanged: why the learniq register is absent at that moment, and why the shard table for at least one schema (openregister_table_14_20, Course) is consequently never created.

[rubenvdlinde]

Correction: found the real cause, and it is not register seeding

I was wrong in both the description and my follow-up. The register-seeding evidence is real but it is not what caused this 404.

OpenRegister resolves a schema identifier by slugifying it and matching the slug. DossierNote slugifies to dossiernote; the declared slug is dossier-note. Measured live:

request	result
.../objects/learniq/DossierNote	404
.../objects/learniq/dossier-note	200
.../objects/learniq/BehaviourIncident	404
.../objects/learniq/behaviour-incident	200

All five schemas PupilDossierTimelineView.loadAll() requests are multi-word, so all five 404'd. A single-word title hides it — Course slugifies to course and resolves — which is why the same PascalCase pattern reads as correct everywhere else in the app.

ExamCaseDossierView already carries a detailed warning about exactly this, from when the same bug was found there. This was the same defect in the one view nobody had reached yet.

Fixed in #622.

What I got wrong, and why

I anchored on [RegisterMapper] Register does not exist … identifier=learniq because I had it in hand from the CI server log. It is a genuine seed-time event, but it happens at 07:04 in a CLI context and never during the test window — I even noted that when I first found it and then reasoned from it anyway.

The actual cause was reachable by asking the endpoint directly, which took one curl loop.

Still open, separately

The seeding evidence remains unexplained and worth its own look, independent of this view:

[RegisterMapper] Register does not exist before filters   identifier=learniq   (x2)
[MagicMapper] relation "oc_openregister_table_14_20" does not exist          (Course)

Nothing currently observes it, since the tests that would have are passing. I am leaving this issue open for that half only, retitled in spirit: why is the learniq register absent at seed time, and why is at least one shard table not created. ConductionNL/openregister#2871 makes that log line say which cause it was, so the next occurrence is diagnosable.