microsoft / microsoft/fhir-server
SearchParameterNotSupportedException thrown on all requests
Nessuno ha ancora preso questa issue.
- Lingua principale
- TSQL
- Stelle
- 1.4k
- Fork
- 592
- Merge medio
- 2g 7h
- PR unite (30g)
- 41
Descrizione
**Describe the bug**
We had been running version 4.0.632 of the server and recently upgraded to version 4.0.790. The upgrade involved running the SQL schema diff scripts from schema version 102 to schema version 113 before running the 4.0.790 image version. Following this, the server has been returning an error for all requests, e.g.
```
{
"resourceType": "OperationOutcome",
"id": "301ce81d-b85e-4c26-ba5d-3ae6a312be61",
"meta": {
"lastUpdated": "2026-06-30T15:05:43.6885012+00:00"
},
"issue": [
{
"severity": "error",
"code": "not-supported",
"details": {
"text": "The request was invalid."
},
"diagnostics": "The search parameter '_type' is not supported for resource type 'Resource'."
}
]
}
```
This is happening because a `SearchParameterNotSupportedException` is being thrown on various code paths, including building a CapabilityStatement, so is possibly throwing on everything that needs to do a search. I've traced through the code as best I can for a metadata request (so very simple, no parameters) and it looks like `SearchParameterDefinitionManager.TryGetFromTypeLookup` must be returning false: https://github.com/microsoft/fhir-server/blob/release/4.0.790/src/Microsoft.Health.Fhir.Core/Features/Definition/SearchParameterDefinitionManager.cs#L556. The parameter `_type` for resource type `Resource` is being added in `SearchOptionsFactory` via `ResourceTypeSearchParameter`: https://github.com/microsoft/fhir-server/blob/release/4.0.790/src/Microsoft.Health.Fhir.Shared.Core/Features/Search/SearchOptionsFactory.cs#L389. I haven't got to the bottom of how the type lookup inside `SearchParameterDefinitionManager` is populated so am a bit stumped at the moment.
There are now a couple of later releases that I could try but I'm a bit wary of changing anything further in case things go even more wrong. Looking at the changes between 4.0.632 and 4.0.790 there are various mentions of search parameters but difficult for me to tell if anything is relevant. Given that the whole thing is completely borked presumably others would have seen it, so possibly it's something to do with our data (although I don't think we do anything unusual).
**FHIR Version?**
Stu3
**Data provider?**
SQL Server
**To Reproduce**
Steps to reproduce the behavior:
1. (Unsure if relevant) Upgrade SQL schema from version 4.0.632 to 4.0.790
2. Run server at 4.0.790
3. Make any query
**Expected behavior**
Well formed queries should return without error.
**Actual behavior**
An error is returned on every query.
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Direzione di ricerca
Start by comparing the 4.0.632-to-4.0.790 SQL schema changes and reproducing a query against the 4.0.790 server. Trace SearchOptionsFactory.cs at ResourceTypeSearchParameter into SearchParameterDefinitionManager.cs at TryGetFromTypeLookup, including how the type lookup is populated. Done means well-formed queries and metadata or CapabilityStatement requests no longer fail with SearchParameterNotSupportedException.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- sql
- Ambito
- backend-api-design, databases
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Attiva
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 42/100