PR #7539: CapabilityStatement incorrectly advertises _include and _revinclude when not supported by the server

5 views
Skip to first unread message

Tanmay Darmorha

unread,
10:53 AM (2 hours ago) 10:53 AM
to HAPI FHIR
Hi HAPI FHIR community,

I've opened a pull request (#7539) about 2 months ago that fixes a correctness issue in ServerCapabilityStatementProvider and wanted to bring it to the community's attention in hopes of getting a review from the maintainers.

The problem (Issues #3042 and #3150)

HAPI FHIR's ServerCapabilityStatementProvider was auto-generating searchInclude and searchRevInclude entries in the CapabilityStatement by inferring them from reference-type search parameters — even when no @IncludeParam annotations were explicitly declared on the server. This causes the server to falsely advertise support for _include and _revinclude to clients, which violates the FHIR specification. The official FHIR documentation states that these lists should be empty when the server does not actually support these parameters.

What the PR does

- Removes the default auto-inference of searchInclude entries in ServerCapabilityStatementProvider that was triggered when no @IncludeParam(allow = {...}) was declared
- Removes the equivalent auto-inference behavior for searchRevInclude, which previously scanned all resource types for reference params targeting the current resource
- Adds tests covering explicit includes, unspecified includes, and disabled revIncludes to improve coverage and prevent regression

PR link: https://github.com/hapifhir/hapi-fhir/pull/7539

I use HAPI FHIR professionally in a production FHIR server, and this bug directly impacts us. Because the framework auto-generates these entries without any explicit declaration on our part, we have no clean way to suppress them without patching the library ourselves. A FHIR server advertising capabilities it does not actually support is a serious correctness issue — clients rely on the CapabilityStatement to know what queries are valid, so false entries can cause real interoperability problems.

The PR has been open since February 6, 2026 and is awaiting a review from someone with write access. If any maintainer has bandwidth to take a look, I'd really appreciate it. Happy to address any feedback or adjust the approach if needed.

Thank you for the great project and your time!

Tanmay
Reply all
Reply to author
Forward
0 new messages