Unable to disable InMemorySubscriptionMatcher using standard configuration method

[jcdufour]

Hello HAPI FHIR team,

I am seeking help with a persistent issue regarding subscription configuration in the hapi-fhir-jpaserver-starter project. My goal is to disable the InMemorySubscriptionMatcher to use the default DatabaseSubscriptionMatcher for rest-hook notifications.

Despite extensive debugging, I have been unable to change this behavior.

Environment:

Project: hapi-fhir-jpaserver-starter
Deployment: Running as a systemd service on a Linux server.
Execution command: java -jar /path/to/target/ROOT.war
Symptom:
Every Subscription resource created via the REST API is systematically assigned the following meta.tag, indicating that the in-memory strategy is being used:{ "system": "http://hapifhir.io/fhir/StructureDefinition/subscription-matching-strategy", "code": "IN_MEMORY" }

As a result, no notifications are ever delivered, and the logs show the background job attempting to submit "0 resources".

Debugging Steps Performed (All Unsuccessful):

I have tried every standard Spring Boot configuration method to override the default behavior, without success.

Internal application.yaml Configuration:

Modified src/main/resources/application.yaml to include both hapi.fhir.subscription.matcher.in-memory-enabled: false and later hapi.fhir.subscription.enable-in-memory-subscription-matching: false.
Performed a full project rebuild with mvn clean package after each change (including manually deleting the previous ROOT.war to ensure freshness).
Result: No effect. The IN_MEMORY tag persisted.
External Configuration (via --spring.config.location):

Modified the systemd service file to launch with the argument --spring.config.location=file:/etc/hapi-fhir/application.yaml.
The external file's path, content, and permissions were triple-checked and confirmed to be correct.
Result: No effect. The argument appears to be ignored.
External Configuration (via Convention):

Placed the application.yaml file in a config/ directory adjacent to the ROOT.war (/target/config/application.yaml).
Result: No effect. The file appears to be ignored.
External Configuration (via Command-Line Argument Override):

Modified the systemd service to launch with --hapi.fhir.subscription.enabled=true and --hapi.fhir.subscription.enable-in-memory-subscription-matching=false.
Result: The enabled=true argument worked (a "Subscriptions are disabled" log message disappeared), but the argument to disable the in-memory matcher was ignored.
Diagnostics via Spring Boot Actuator:

Enabled the /actuator/env endpoint via a command-line argument.
Querying this endpoint revealed that no property related to in-memory-enabled was present in the application's loaded environment, suggesting the application is falling back to a hard-coded default.
Final Conclusion:

The evidence strongly suggests that this version of the hapi-fhir-jpaserver-starter contains a Java-based configuration (@Configuration/@bean) that programmatically and unconditionally enables the InMemorySubscriptionMatcher. This Java configuration seems to take precedence over all standard Spring Boot configuration methods.

My Question:

Is there a specific, and perhaps undocumented, configuration property to disable this behavior? Or is modifying the Java source code the only way to enable the database-backed subscription matcher in this project?

Thank you for your time and for maintaining this excellent project. Any guidance would be greatly appreciated.

PS: To make this report as clear and comprehensive as possible, I used an AI assistant to help structure this message in English. Please be assured that I personally drove the entire debugging process and have carefully reviewed and edited this text to ensure it is an exact reflection of my situation.

[jcdufour]

Hello,

My apologies, I realize I forgot to include a crucial piece of information in my original report: the HAPI FHIR version we are using.

After checking the pom.xml file, the version is 8.0.0.

I hope this additional detail helps with the diagnosis. Thank you again for your time and assistance.

Best regards,

[jcdufour]

Hello,

Just a quick follow-up to my report.

To ensure this wasn't a bug in an older version, I have now successfully upgraded my project from HAPI FHIR 8.0.0 to 8.2.0.

Unfortunately, I can confirm that the issue persists exactly as described before. Newly created Subscription resources are still being assigned the IN_MEMORY matching strategy, and notifications are not being delivered.

Thank you.

[jamesagnew]

I don't understand why you would want this. The In-Memory subscription matcher is functionally identical to the database one, but more efficient. There shouldn't be any change in behaviour by disabling it, which is why we don't provide a way. If you have a test case where you believe it's behaving incorrectly, if you can demonstrate it by adding to this test we could investigate.

[jcdufour]

Hello,

To clarify, my initial attempts to switch to a database matcher were an effort to work around the issue. I now agree that the core problem to demonstrate is the failure of the default InMemorySubscriptionMatcher.

Thank you for the guidance. As requested, I have created a manual test case with the InMemorySubscriptionMatcher.

I can confirm the server is running correctly (HAPI FHIR v8.0.0 starter, java -jar deployment). Basic FHIR operations, including reads by ID and search queries, are working correctly, which proves the persistence and search layers are functional.

Here is the step-by-step reproducible test case:

1. Endpoint Verification:
   First, I confirmed that the target endpoint is running and reachable from the HAPI FHIR server. The following command, run from the server's command line, successfully sends a message to my listening application:

curl -X POST -H "Content-Type: application/json" -d '{"test": "Direct connectivity test"}' http://localhost:5005/cds

2. Subscription Creation:Next, I created a new, active Subscription on the running server with the following payload:
   {
   "resourceType": "Subscription",
   "status": "active",
   "reason": "Bug report test case",
   "criteria": "MedicationRequest?status=active",
   "channel": {
   "type": "rest-hook",
   "endpoint": "http://localhost:5005/cds",
   "payload": "application/json"
   }
   }
   The server created the resource successfully and correctly assigned it the IN_MEMORY matching strategy tag.

3. Triggering Event:
   Finally, I created a MedicationRequest resource that perfectly matches the subscription's criteria:

{
"resourceType": "MedicationRequest",
"status": "active",
"intent": "order",
"medicationReference": { "reference": "Medication/2" },
"subject": { "reference": "Patient/1" }
}
The resource was created successfully with a 201 Created response.

Results
Expected Behavior:
The HAPI FHIR server should match the newly created MedicationRequest, queue one notification, and send a POST request to the endpoint at http://localhost:5005/cds.

Actual Behavior:
No POST request is ever sent to the endpoint. The server logs at the exact moment of the MedicationRequest creation show the following, which proves the matching step failed:

INFO ... fhirtest.access ... Operation[create MedicationRequest] UA[curl/7.81.0] ...
DEBUG ... .j.s.a.AsyncResourceModifiedSubmitterSvc : Attempting to submit 0 resources to consumer channel.
Conclusion:

This test case demonstrates that even though the server is fully operational and its general search capabilities are working, the InMemorySubscriptionMatcher specifically fails to evaluate the MedicationRequest?status=active criteria and does not queue a notification for delivery. This appears to be the bug you suggested might exist.

Here are the relevant sections of my application.yaml to provide full context on how the server is configured. Please note that the server is successfully connecting to the database and running basic search queries.

Relevant parts of application.yaml

spring:
flyway:
enabled: true

datasource:
url: jdbc:postgresql://localhost:5432/hapi_fhir_db
username: hapi_fhir_user
password: '[REDACTED_FOR_SECURITY]'
driver-class-name: org.postgresql.Driver

jpa:
properties:
hibernate.dialect: ca.uhn.fhir.jpa.model.dialect.HapiFhirPostgresDialect

hapi:
fhir:
fhir_version: R4

subscription:
  enabled: true
  resthook:
    enabled: true
  supported-types:
    - rest-hook

I hope this detailed, reproducible case is helpful. Please let me know if you need any more information.

Thank you for your help.

[jamesagnew]

The fact that it says "about to submit 0 messages" is suspect. When your MR resource is being saved, a record should be saved on a queueing table called HFJ_RESOURCE_MODIFIED which is used to spool resources for subscription processing. A first step in troubleshooting could be to put a breakpoint in SubscriptionMatcherInterceptor to confirm that your resource is getting persisted by ResourceModifiedMessagePersistenceSvcImpl. If it looks like it is, the next place to check is ResourceModifiedMessagePersistenceSvcImpl#findOrderedByCreateTime to see whether the resource is then being retrieved. Cheers, James

…

On Thu, Jun 12, 2025 at 8:43 AM Jean-Charles DUFOUR < ***@***.***> wrote: *jcdufour* left a comment (hapifhir/hapi-fhir-jpaserver-starter#832) <#832 (comment)> Hello, To clarify, my initial attempts to switch to a database matcher were an effort to work around the issue. I now agree that the core problem to demonstrate is the failure of the default InMemorySubscriptionMatcher. Thank you for the guidance. As requested, I have created a manual test case with the InMemorySubscriptionMatcher. I can confirm the server is running correctly (HAPI FHIR v8.0.0 starter, java -jar deployment). Basic FHIR operations, including reads by ID and search queries, are working correctly, which proves the persistence and search layers are functional. Here is the step-by-step reproducible test case: 1. Endpoint Verification: First, I confirmed that the target endpoint is running and reachable from the HAPI FHIR server. The following command, run from the server's command line, successfully sends a message to my listening application: curl -X POST -H "Content-Type: application/json" -d '{"test": "Direct connectivity test"}' http://localhost:5005/cds 2. Subscription Creation:Next, I created a new, active Subscription on the running server with the following payload: { "resourceType": "Subscription", "status": "active", "reason": "Bug report test case", "criteria": "MedicationRequest?status=active", "channel": { "type": "rest-hook", "endpoint": "http://localhost:5005/cds", "payload": "application/json" } } The server created the resource successfully and correctly assigned it the IN_MEMORY matching strategy tag. 3. Triggering Event: Finally, I created a MedicationRequest resource that perfectly matches the subscription's criteria: { "resourceType": "MedicationRequest", "status": "active", "intent": "order", "medicationReference": { "reference": "Medication/2" }, "subject": { "reference": "Patient/1" } } The resource was created successfully with a 201 Created response. Results Expected Behavior: The HAPI FHIR server should match the newly created MedicationRequest, queue one notification, and send a POST request to the endpoint at http://localhost:5005/cds. Actual Behavior: No POST request is ever sent to the endpoint. The server logs at the exact moment of the MedicationRequest creation show the following, which proves the matching step failed: INFO ... fhirtest.access ... Operation[create MedicationRequest] UA[curl/7.81.0] ... DEBUG ... .j.s.a.AsyncResourceModifiedSubmitterSvc : Attempting to submit 0 resources to consumer channel. Conclusion: This test case demonstrates that even though the server is fully operational and its general search capabilities are working, the InMemorySubscriptionMatcher specifically fails to evaluate the MedicationRequest?status=active criteria and does not queue a notification for delivery. This appears to be the bug you suggested might exist. Here are the relevant sections of my application.yaml to provide full context on how the server is configured. Please note that the server is successfully connecting to the database and running basic search queries. Relevant parts of application.yaml spring: flyway: enabled: true datasource: url: jdbc:postgresql://localhost:5432/hapi_fhir_db username: hapi_fhir_user password: '[REDACTED_FOR_SECURITY]' driver-class-name: org.postgresql.Driver jpa: properties: hibernate.dialect: ca.uhn.fhir.jpa.model.dialect.HapiFhirPostgresDialect hapi: fhir: fhir_version: R4 subscription: enabled: true resthook: enabled: true supported-types: - rest-hook I hope this detailed, reproducible case is helpful. Please let me know if you need any more information. Thank you for your help. — Reply to this email directly, view it on GitHub <#832 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2N7HOFSZPYX6FNDIA4DTD3DFYVPAVCNFSM6AAAAAB7ACVSD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNRWGU3DIOBSGI> . You are receiving this because you commented.Message ID: ***@***.***>

[jcdufour]

Hello,

Thank you for the excellent diagnostic guidance regarding the HFJ_RESOURCE_MODIFIED table. I have performed the test as you suggested.

Here are the results:

Before creating the resource, I checked the queueing table:
SELECT count(*) FROM hfj_resource_modified;
Result: 0

I then created a MedicationRequest resource that perfectly matches the criteria of an active Subscription (MedicationRequest?status=active). The resource was created successfully.

Immediately after creating the resource, I checked the queueing table again:
SELECT count(*) FROM hfj_resource_modified;
Result: 0

Conclusion:
This definitively proves that the resource creation event is not being spooled to the HFJ_RESOURCE_MODIFIED queueing table. The row count does not change.

This indicates the failure occurs very early in the pipeline, before ResourceModifiedMessagePersistenceSvcImpl can persist the message, possibly within the SubscriptionMatcherInterceptor itself.

I hope this provides the specific information you need to investigate this bug. Thank you again for your help.

[jcdufour]

Hello,

I have performed another test. The results confirm a bug early in the subscription processing pipeline.

Test 1: Direct Database Check
See my previous message

Test 2: Detailed Logging
To find out why, I enabled TRACE level logging on the following key classes in the application.yaml :

ca.uhn.fhir.jpa.subscription.interceptor.SubscriptionMatcherInterceptor

ca.uhn.fhir.jpa.subscription.match.registry.ResourceModifiedMessagePersistenceSvcImpl

After restarting and creating a new MedicationRequest, NO TRACE logs from either of these classes appear in the server logs. The only relevant log is the standard INFO log for the resource creation, followed later by the DEBUG log from the queue poller stating it has 0 resources to submit.

Conclusion:
I think this proves that the SubscriptionMatcherInterceptor is not being invoked at all for the MedicationRequest write operation. The issue seems to be a fundamental problem in the interceptor chain dispatching for this resource type, preventing the subscription process from ever starting.

I am reporting this from an end-user/administrator perspective. As I am unable to set breakpoints and debug the Java code directly, I used the database checks and detailed TRACE logging to gather this evidence instead.

I hope this provides the specific information you need to investigate this bug.

Thank you again for your help.