Repository navigation
spp_api_v2_* / spp_dci_server: identifier lookups outside spp_api_v2 still take the first match and resolve soft-removed IDs #557
Description
Problem
PR #555 (#554 item I) made spp_api_v2 and spp_api_v2_programs resolve an identifier to exactly one registrant:
a shared resolver (spp_api_v2/services/registrant_resolver.py) ignores soft-removed (status = 'invalid') IDs and
refuses (409 / anti-enumeration 403) when several registrants hold the identifier. The registry allows shared ID values
by design (spp.deduplication.manager.id_dedup finds them), so any lookup that takes the first match can act on the
wrong registrant.
These lookups were out of that PR's scope and still pick an arbitrary match:
| Module | Location | Pattern |
|---|---|---|
spp_api_v2_entitlements |
services/entitlement_service.py (~231) |
spp.registry.id search limit=1 |
spp_api_v2_change_request |
services/change_request_service.py (~92) |
spp.registry.id search limit=1 |
spp_api_v2_data |
routers/data.py (~60) |
spp.registry.id search limit=1 |
spp_dci_server |
routers/bulk_upload.py (~509) |
batch search on id_type_id.namespace_uri (not the code URI), last match wins per key, no invalid filter |
Proposal
Route these through registrant_resolver.resolve_registrant / resolve_registrants (and the router helpers in
spp_api_v2/utils/registrant_lookup.py for the consent-aware 409/403), with tests seeding a duplicated identifier and
a soft-removed one. For the DCI bulk upload, decide how a duplicated identifier is reported per record.
Context
Decision D6 of #554.
Activity