Register scoping (#2774) fallout: three distinct breakages, two already double-patched

[rubenvdlinde]

Opening this rather than adding a fourth change to a subsystem that took five merges today, two of which fix the same leak twice.

Bisected: #2774 is the window

integriq's flow-native-sync.spec.ts:876 is deterministically red on development (two runs + a Playwright retry). By job timestamps:

passed (integriq#1526)	07:48–08:07 UTC
failed (development)	08:46–09:05 UTC

The only behavioural change in openregister development inside that window is #2774 — "make {register} a hard boundary on every path that names one", the commit that introduced RegisterScopedSchemaResolver.

Not caused by #2790: that merged 10:57 UTC, ~2h after the first failure.

Symptom 1 — a schema-only lookup inherits an unrelated register (CI)

object-write fails mid-flow:

Schema slug "synchronization_contract" is not carried by register
"fns-mt4du8ca-62fj-reg" (id 15), which carries 2 schema(s).
1 schema(s) elsewhere on this instance carry this slug

synchronization_contract lives in the openconnector register. The register named in the error is the test's own register, created by the spec with 2 schemas. Every openconnector call site I checked (SynchronizationContractService, SynchronizationService:999/1459/1494/1542, SynchronizationContractProvider) names register: 'openconnector' explicitly — so this is a lookup picking up a sticky register it never named.

Symptom 2 — the same shape, different slug (dev instance)

Every openconnector object read failed with Schema slug "application" is not carried by register "openconnector" while the caller had asked for synchronization. Diagnosed as the pending schema ref leaking across callers; fixed in #2790, and #2792 independently fixed the same mechanism 12 minutes later. Two fixes, one bug — worth reconciling.

Symptom 3 — the objects API cannot resolve ANY register (dev instance)

Reproducible with plain curl, by slug and by id, while the registers API resolves the same register fine:

GET /api/registers/65                      -> 200, register 65 "openconnector"
GET /api/objects/openconnector/synchronization -> {"message":"Register not found: 'openconnector'"}
GET /api/objects/65/synchronization            -> {"message":"Register not found: '65'"}

The e2e hits this too: a register it has just created comes back Register not found: '4895'.

Why this was invisible for hours

FlowEngine logs a throwing step as status: 'failed' with the message in that entry's error, then returns a run whose status is stopped and whose run-level error is null. Since stopped counts as successful, a run that died mid-pipeline satisfied "terminal", "successful" and "no error" simultaneously. Only a separate step-list assertion noticed, and it reported a missing-steps diff — which reads like a routing bug and sent me a full CI round in the wrong direction.

Fixed on the integriq side (assert no step has status: failed, and interpolate the engine's message, since the run object carries it nowhere else). Worth considering whether the run-level error should be populated when a step fails — right now the API's own summary of a failed run says nothing failed.

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

Independent confirmation from a controlled bisect, plus a known-good reference you can use.

I initially suspected aa886cb37 (the PHPStan-2 migration) and filed #2799 for it. Your analysis was right and mine was not — a controlled run settles it:

openregister pin	result	flow-native-sync.spec.ts:876
development	170 passed, 1 failed	✘
aa886cb37^	175 passed, 0 failed	✓
development with only SaveObject.php reverted	170 passed, 1 failed	✘

Reverting the file I suspected changes nothing, so the PHPStan-2 migration is not implicated. #2799 is closed as a duplicate of this issue.

Useful for fixing this: ConductionNL/openregister@experiment/pre-phpstan2-bisect is a branch at aa886cb37^ that is known green for this spec (175 passed, 0 failed). A candidate fix for #2774 can be compared against a reference that actually passes, rather than against a red baseline where a partial improvement is invisible.

One gotcha if you pin openregister yourself: additional-apps does git clone --branch <ref> and cannot resolve a raw SHA. My first attempt died with fatal: Remote branch <sha> not found in upstream origin before any test ran and reported plain failure — indistinguishable from a red test run. If a pinned run fails with no N passed line in the log, it did not execute; pin to a branch name.