Context
OpenRegister PR #1430 (issue #1428) changes the wire format of the schemas array on registers when expanded via _extend=schemas:
Before: orphan schema IDs (where the referenced schema no longer exists) were silently dropped — the schemas array contained only resolvable Schema objects.
After: orphan schema IDs are kept in the response as bare integer IDs alongside the resolved Schema objects. The array is no longer homogeneous; consumers must handle both shapes.
Example after the change:
```json
{
"@self": {
"schemas": [
{ "id": 12, "slug": "person", ... },
42,
{ "id": 13, "slug": "address", ... }
]
}
}
```
Why softwarecatalog cares
If softwarecatalog calls GET /api/registers?_extend=schemas (directly or transitively via opencatalogi / docudesk / any OR-backed registry surface) AND decodes the schemas field into a homogeneous Go/PHP/TS array of Schema structs, the bare-integer entries will silently misparse — typically as zero-valued structs or a JSON-decode error depending on the language and decoder strictness.
Ask
Please audit the []Schema decoder paths in softwarecatalog (and any client/SDK that ships with it) for:
- Registers fetched with
_extend=schemas — confirm the decoder either accepts a heterogeneous array or filters bare IDs upfront.
- Tests that assert array-element shape — they will pass today on registers without orphans and break once an orphan exists in the wild.
Mitigation if affected: switch to a tagged union decoder (oneOf: integer | Schema), or post-process the response client-side to filter integers before deserialising into Schema.
Tracking back
This issue tracks the cross-repo audit referenced in openregister PR #1430 task 7.1 and review comment. DocuDesk has a parallel audit tracked in ConductionNL/docudesk#120.
Status
Open for triage by the softwarecatalog maintainers — no immediate action required on the OpenRegister side; this is a heads-up for downstream consumers.
Context
OpenRegister PR #1430 (issue #1428) changes the wire format of the
schemasarray on registers when expanded via_extend=schemas:Before: orphan schema IDs (where the referenced schema no longer exists) were silently dropped — the
schemasarray contained only resolvableSchemaobjects.After: orphan schema IDs are kept in the response as bare integer IDs alongside the resolved
Schemaobjects. The array is no longer homogeneous; consumers must handle both shapes.Example after the change:
```json
{
"@self": {
"schemas": [
{ "id": 12, "slug": "person", ... },
42,
{ "id": 13, "slug": "address", ... }
]
}
}
```
Why softwarecatalog cares
If
softwarecatalogcallsGET /api/registers?_extend=schemas(directly or transitively via opencatalogi / docudesk / any OR-backed registry surface) AND decodes theschemasfield into a homogeneous Go/PHP/TS array ofSchemastructs, the bare-integer entries will silently misparse — typically as zero-valued structs or a JSON-decode error depending on the language and decoder strictness.Ask
Please audit the
[]Schemadecoder paths in softwarecatalog (and any client/SDK that ships with it) for:_extend=schemas— confirm the decoder either accepts a heterogeneous array or filters bare IDs upfront.Mitigation if affected: switch to a tagged union decoder (
oneOf: integer | Schema), or post-process the response client-side to filter integers before deserialising intoSchema.Tracking back
This issue tracks the cross-repo audit referenced in openregister PR #1430 task 7.1 and review comment. DocuDesk has a parallel audit tracked in ConductionNL/docudesk#120.
Status
Open for triage by the softwarecatalog maintainers — no immediate action required on the OpenRegister side; this is a heads-up for downstream consumers.