Resolver returns empty results for namespace-level entity queries with empty match_nodes #11

What

Many entity registry entries have `match_nodes: []` — the entry holds namespace-level metadata (official_name, common_name, urls, etc.) but doesn't pattern-match any specific products or services. When a client queries one of these at the namespace level, the resolver returns `status: "found"` but `results: []`.

Example:

```
$ curl 'https://secid.cloudsecurityalliance.org/api/v1/resolve?secid=secid:entity/adobe.com'
{
"secid_query": "secid:entity/adobe.com",
"status": "found",
"results": []
}
```

But the data IS in the registry:

```
$ curl 'https://secid.cloudsecurityalliance.org/api/v1/registry.json' | jq '.entity["adobe.com"]'
{
"namespace": "adobe.com",
"type": "entity",
"official_name": "Adobe Systems Incorporated",
"urls": [...],
"match_nodes": []
}
```

Scope

Affects every entity entry with empty match_nodes. Before today's sweep that was ~50 entries; after CloudSecurityAlliance/SecID#83 it's ~525 entries (475 new auto-generated stubs + the older ones).

Also potentially affects entries in other types with empty match_nodes, though I haven't audited.

Proposed fix

When the parsed query has a type+namespace but no name, and the namespace's match_nodes is empty (or doesn't exist), return a `RegistryResult` carrying the namespace-level metadata: `official_name`, `common_name`, `alternate_names`, `notes`, `urls`, `wikidata`, `wikipedia`. So:

```json
{
"secid_query": "secid:entity/adobe.com",
"status": "found",
"results": [
{
"secid": "secid:entity/adobe.com",
"data": {
"official_name": "Adobe Systems Incorporated",
"urls": [{"type": "website", "url": "https://adobe.com"}],
"source_count": 0
}
}
]
}
```

This mirrors what `listSources` does for a namespace with match_nodes, just without the per-source enumeration.

Code location (best guess)

`src/resolver.ts` — the `listSources` function handles the namespace-level case. It already iterates `ns.match_nodes.map(...)`; when that array is empty, the resulting array is empty (which is the current behavior). The fix is to return a single fallback RegistryResult with the namespace metadata in that case.

Acceptance criteria

• `curl secid:entity/adobe.com` returns one result with the metadata, status "found"
• `curl secid:entity/cisco.com` (which HAS match_nodes) returns its match_node listings unchanged
• Same fix works for other types — control entries with empty match_nodes, reference entries with empty match_nodes, etc.

Related

• CloudSecurityAlliance/SecID#83 — added 475 entity stubs that made this gap more visible
• The pre-existing entity entries (Amazon, etc.) have always had this behavior; the new stubs just multiply the visible cases

🤖 Generated from session