SearchParameterNotSupportedException thrown on all requests

[tswelsh]

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.

[tswelsh]

We've come back to this and tracked it down to the fact that there is a search parameter with uri http://hl7.org/fhir/SearchParameter/Resource-type in dbo.SearchParam with status Supported. This corresponds to the _type search parameter. Judging by the comment here perhaps it shouldn't have found its way into the DB at all. It's not in there in our other environments which haven't undergone an update.

[tswelsh]

Some more Friday afternoon debugging . . .

The http://hl7.org/fhir/SearchParameter/Resource-type search parameter is being inserted into dbo.SearchParam on startup via the dbo.InitializeBase stored procedure. This proc takes in all the search parameters as defined by SearchParameterDefinitionManager.AllSearchParameters and ensures that they are present in the table. The Resource-type parameter did not used to be present in AllSearchParameters but evidently now is. The change to do this was made in 4493ae1, in which a change was made so that the Resource-type parameter was added to a lookup when it wasn't before. The knock-on effect is it appears in AllSearchParameters and then gets added to the table in the initialise proc.

I might try upgrading to the latest release next week, but at release/5.0.0 that line is still there: https://github.com/microsoft/fhir-server/blob/release/5.0.0/src/Microsoft.Health.Fhir.Core/Features/Definition/SearchParameterDefinitionBuilder.cs#L223.

Can anybody advise on this? It definitely feels like a bug, but also one that anybody running with the same configuration would have hit. Perhaps there aren't many people running STU3 with SQL Server, but still.

[davidbarwin-stemsoft]

We are seeing this as well with FHIR R4. We will be upgrading to 5.0.30 to check again as the release notes for that version include #5724 which sounds related.

[davidbarwin-stemsoft]

5.0.30

Issue still appears to occur in the 5.0.37 release

[evachen96]

David Barwin (@davidbarwin-stemsoft) Could you share the query that you are using?

[davidbarwin-stemsoft]

David Barwin (@davidbarwin-stemsoft) Could you share the query that you are using?

The failure immediately occurs when getting the capability statements.

Expected:
GET https://localhost:44348/metadata returns HTTP 200 with an R4 CapabilityStatement.

Actual:
The request returns an OperationOutcome. While constructing the
CapabilityStatement, the server throws SearchParameterNotSupportedException
while resolving Resource/_type (http://hl7.org/fhir/SearchParameter/Resource-type).

This only occurs with a SQL server database that has been upgraded. A fresh database is populated correctly and works fine.

The specific issue is the existence of the Resource-type record in the dbo.SearchParam table. The record does not exists in the database until the first time the FhirServer binaries are executed, i.e. there is initialization code that is inserting this rather than schema migration scripts. It's inserted with a "Supported" status which is what causes the issue.

In contrast, a fresh instance database has the same record with status "Enabled" which is what the code expects.

We believe the issue is in Microsoft.Health.Fhir.SqlServer\Features\Storage\SqlServerFhirModel.cs InitializeSearchParameterStatuses. The logic at approx line 442 has a check that is resulting in the wrong status being set in the search parameter when there are existing resources in the database.

After initialization if we manually set Resource-type to Enabled in dbo.SearchParam the capability statement returns correctly.