Skip to content

Disability DCI sync search returns HTTP 500 for multi-item search_request #217

@jeremi

Description

@jeremi

Summary

The OpenSPP Disability Registry DCI synchronous search endpoint returns a raw HTTP 500 when the DCI envelope contains more than one search_request item.

Single-item search works on the same endpoint. The multi-item request should either return a DCI response envelope with one response item per request item, or return a clean validation error if batching is intentionally unsupported.

Endpoint

POST /dci_api/v1/disability/registry/sync/search

Base tested against the demo server on 2026-05-26:

https://openspp-dci-demo-dr.genete.acn.fr

Steps to reproduce

Send a DCI envelope with header.total_count = 2 and two entries under message.search_request, for example:

{
  "signature": "",
  "header": {
    "message_id": "<uuid>",
    "message_ts": "2026-05-26T00:00:00Z",
    "action": "search",
    "sender_id": "registry-witness",
    "receiver_id": "openspp",
    "total_count": 2,
    "is_msg_encrypted": false
  },
  "message": {
    "transaction_id": "<uuid>",
    "search_request": [
      {
        "reference_id": "<uuid-1>",
        "timestamp": "2026-05-26T00:00:00Z",
        "search_criteria": {
          "query_type": "idtype-value",
          "query": {
            "type": "NATIONAL_ID",
            "value": "<known-existing-national-id>"
          },
          "pagination": { "page_size": 2 }
        }
      },
      {
        "reference_id": "<uuid-2>",
        "timestamp": "2026-05-26T00:00:00Z",
        "search_criteria": {
          "query_type": "idtype-value",
          "query": {
            "type": "NATIONAL_ID",
            "value": "registry-witness-smoke-test"
          },
          "pagination": { "page_size": 2 }
        }
      }
    ]
  }
}

Use the same bearer token/header setup that works for a single-item search request.

I can provide the exact test identifiers privately if useful, but avoided including them in this public issue body.

Actual result

The endpoint returns:

HTTP/1.1 500 Internal Server Error
content-type: application/json
{"detail":"Internal Server Error"}

Expected result

One of:

  1. A DCI on-search response envelope with two message.search_response entries, preserving reference_id correlation. For example, one succ item for the existing record and one rjct / not-found item for the missing record.
  2. If multi-item search is not supported, a deterministic 4xx validation response explaining that only one search_request item is accepted.

A raw 500 makes clients treat the registry as unavailable and prevents safe use of DCI batch search.

Additional interop observations

While testing the OpenAPI surface at /dci_api/v1/openapi.json, I also noticed:

  • /.well-known/jwks.json is documented for response signature verification but returned {"keys": []} on the demo server. If intentional for the demo, no action needed, but it blocks response-signature verification.
  • /crvs/registry/sync/search and /farmer/registry/sync/search are documented as accepting DCIEnvelope, but envelope-shaped probes returned 422 validation errors asking for transaction_id and search_request at the top level. If those routes are placeholders, it may be worth documenting that in the OpenAPI descriptions or aligning the request schema.

Context

This came up while integrating Registry Witness with the OpenSPP Disability Registry DCI API as a backend. Single-item Disability DCI search works, and Registry Witness can issue an SD-JWT VC from the returned Disability Registry record. The main blocker for enabling DCI batched search is the 500 on multi-item search_request.

Metadata

Metadata

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions