search

hapifhir / hapi-fhir-jpaserver-starter

Apache License 2.0
377 stars 1.02k forks source link

search does not work with partitioning #163

Closed camerondavison closed 3 years ago

camerondavison commented 3 years ago

I checked out the latest source code e05d950c474a90864fbf9c6d0428b2bf02676902

Made the following change to the application.yaml file

diff --git a/src/main/resources/application.yaml b/src/main/resources/application.yaml
index b7ec776..9ffe38f 100644
--- a/src/main/resources/application.yaml
+++ b/src/main/resources/application.yaml
@@ -62,10 +62,10 @@ hapi:
 #    fhirpath_interceptor_enabled: false
 #    filter_search_enabled: true
 #    graphql_enabled: true
-    #partitioning:
-    #  cross_partition_reference_mode: true
-    #  multitenancy_enabled: true
-    #  partitioning_include_in_search_hashes: true
+    partitioning:
+      cross_partition_reference_mode: true
+      multitenancy_enabled: true
+      partitioning_include_in_search_hashes: true
     #cors:
     #  allow_Credentials: true
       # Supports multiple, comma separated allowed origin entries

Then ran

mvn jetty:run

Then created 2 partitions and 1 patient in each partition with

curl -s -H 'content-type: application/json' -d '{"resourceType":"Parameters","parameter":[{"name":"id","valueInteger":123},{"name":"name","valueCode":"PARTITION-123"},{"name":"description","valueString":"a description"}]}' 'localhost:8080/fhir/DEFAULT/$partition-management-create-partition'
curl -s -H 'content-type: application/json' -d '{"resourceType":"Parameters","parameter":[{"name":"id","valueInteger":456},{"name":"name","valueCode":"PARTITION-456"},{"name":"description","valueString":"a description"}]}' 'localhost:8080/fhir/DEFAULT/$partition-management-create-partition'

curl -s -H 'content-type: application/json' -d '{"resourceType":"Patient","id":"pid-PARTITION-123","name":[{"family":"Parker"}]}' -XPUT 'localhost:8080/fhir/PARTITION-123/Patient/pid-PARTITION-123?_format=json'
curl -s -H 'content-type: application/json' -d '{"resourceType":"Patient","id":"pid-PARTITION-456","name":[{"family":"Parker"}]}' -XPUT 'localhost:8080/fhir/PARTITION-456/Patient/pid-PARTITION-456?_format=json'

All of that runs correctly.

The first search I do gives back the correct resource.

curl -s http://localhost:8080/fhir/PARTITION-456/Patient | jq '.entry[].fullUrl'
"http://localhost:8080/fhir/PARTITION-456/Patient/pid-PARTITION-456"

But the second search gives back the same resource even though I am searching a different parition

curl -s http://localhost:8080/fhir/PARTITION-123/Patient | jq '.entry[].fullUrl'
"http://localhost:8080/fhir/PARTITION-123/Patient/pid-PARTITION-456"

And given that this resource is not in that partition, any attempt to try and read that resource gives back a 404.

If you restart the server and search in the opposite order it returns the other resource for the wrong partition.

Is there some kind of caching that occurs that is not taking into account the partitions? Because if I update the patient info it also changes.

I update the java code

diff --git a/src/main/java/ca/uhn/fhir/jpa/starter/FhirServerConfigCommon.java b/src/main/java/ca/uhn/fhir/jpa/starter/FhirServerConfigCommon.java
index cfe9bde..57f0b0b 100644
--- a/src/main/java/ca/uhn/fhir/jpa/starter/FhirServerConfigCommon.java
+++ b/src/main/java/ca/uhn/fhir/jpa/starter/FhirServerConfigCommon.java
@@ -115,8 +115,10 @@ public class FhirServerConfigCommon {
     PartitionSettings retVal = new PartitionSettings();

     // Partitioning
-    if (appProperties.getPartitioning() != null) {
+    final AppProperties.Partitioning partitioning = appProperties.getPartitioning();
+    if (partitioning != null) {
       retVal.setPartitioningEnabled(true);
+      retVal.setIncludePartitionInSearchHashes(partitioning.getPartitioning_include_in_search_hashes());
     }

to see if using the partitioning_include_in_search_hashes yaml value would help but it did not seem to help.

camerondavison commented 3 years ago

I do think that it has to do with the search cache. I set reuse_cached_search_results_millis to 0 and do not see this same problem.

JoeMcCaffrey commented 3 years ago

https://hapifhir.io/hapi-fhir/apidocs/hapi-fhir-jpaserver-model/ca/uhn/fhir/jpa/model/config/PartitionSettings.html

possibly should be false?

camerondavison commented 3 years ago

Strange. Correct me if I am wrong but https://github.com/hapifhir/hapi-fhir-jpaserver-starter/blob/e05d950c474a90864fbf9c6d0428b2bf02676902/src/main/java/ca/uhn/fhir/jpa/starter/AppProperties.java#L540-L552 it does not look like that setting is actually even used.

Not sure if this helps, but this is me reproducing the steps https://asciinema.org/a/3y72kXNAVsLmIKbxwsj2uj9bS you can see the wrong patient coming back from the search at the very end.

I am sure that it also depends on what version of the libs are being used as a part of the build

❯ mvn dependency:resolve | grep hapi
[WARNING] The project ca.uhn.hapi.fhir:hapi-fhir-jpaserver-starter:war:5.1.0 uses prerequisites which is only intended for maven-plugin projects but not for non maven-plugin projects. For such purposes you should use the maven-enforcer-plugin. See https://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html
[INFO] ------------< ca.uhn.hapi.fhir:hapi-fhir-jpaserver-starter >------------
[INFO] --- maven-dependency-plugin:3.0.2:resolve (default-cli) @ hapi-fhir-jpaserver-starter ---
[INFO] Can't extract module name from hapi-fhir-elasticsearch-6-5.1.0-shaded6.jar: hapi.fhir.elasticsearch.6: Invalid module name: '6' is not a Java identifier
[INFO] Can't extract module name from hapi-fhir-testpage-overlay-5.1.0.war: Module format not recognized: /Users/camerondavison/.m2/repository/ca/uhn/hapi/fhir/hapi-fhir-testpage-overlay/5.1.0/hapi-fhir-testpage-overlay-5.1.0.war
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-base:jar:5.1.0:compile -- module hapi.fhir.base (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-base:jar:5.1.0:compile -- module hapi.fhir.jpaserver.base (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-client:jar:5.1.0:compile -- module hapi.fhir.client (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-server:jar:5.1.0:compile -- module hapi.fhir.server (auto)
[INFO]    ca.uhn.hapi.fhir:org.hl7.fhir.utilities:jar:5.1.0:compile -- module org.hl7.fhir.utilities (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-server-empi:jar:5.1.0:compile -- module hapi.fhir.server.empi (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-subscription:jar:5.1.0:compile -- module hapi.fhir.jpaserver.subscription (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-api:jar:5.1.0:compile -- module hapi.fhir.jpaserver.api (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-searchparam:jar:5.1.0:compile -- module hapi.fhir.jpaserver.searchparam (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-model:jar:5.1.0:compile -- module hapi.fhir.jpaserver.model (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-validation:jar:5.1.0:compile -- module hapi.fhir.validation (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-converter:jar:5.1.0:compile -- module hapi.fhir.converter (auto)
[INFO]    ca.uhn.hapi.fhir:org.hl7.fhir.convertors:jar:5.1.0:compile -- module org.hl7.fhir.convertors (auto)
[INFO]    ca.uhn.hapi.fhir:org.hl7.fhir.validation:jar:5.1.0:compile -- module org.hl7.fhir.validation (auto)
[INFO]    ca.uhn.hapi.fhir:org.hl7.fhir.dstu2016may:jar:5.1.0:compile -- module org.hl7.fhir.dstu2016may (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-structures-dstu2:jar:5.1.0:compile -- module hapi.fhir.structures.dstu2 (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-structures-dstu3:jar:5.1.0:compile -- module hapi.fhir.structures.dstu3 (auto)
[INFO]    ca.uhn.hapi.fhir:org.hl7.fhir.dstu3:jar:5.1.0:compile -- module org.hl7.fhir.dstu3 (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-structures-r4:jar:5.1.0:compile -- module hapi.fhir.structures.r4 (auto)
[INFO]    ca.uhn.hapi.fhir:org.hl7.fhir.r4:jar:5.1.0:compile -- module org.hl7.fhir.r4 (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-structures-r5:jar:5.1.0:compile -- module hapi.fhir.structures.r5 (auto)
[INFO]    ca.uhn.hapi.fhir:org.hl7.fhir.r5:jar:5.1.0:compile -- module org.hl7.fhir.r5 (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-structures-hl7org-dstu2:jar:5.1.0:compile -- module hapi.fhir.structures.hl7org.dstu2 (auto)
[INFO]    ca.uhn.hapi.fhir:org.hl7.fhir.dstu2:jar:5.1.0:compile -- module org.hl7.fhir.dstu2 (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-validation-resources-dstu2:jar:5.1.0:compile -- module hapi.fhir.validation.resources.dstu2 (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-validation-resources-dstu3:jar:5.1.0:compile -- module hapi.fhir.validation.resources.dstu3 (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-validation-resources-r4:jar:5.1.0:compile -- module hapi.fhir.validation.resources.r4 (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-validation-resources-r5:jar:5.1.0:compile -- module hapi.fhir.validation.resources.r5 (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-batch:jar:5.1.0:compile -- module hapi.fhir.jpaserver.batch (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-elasticsearch-6:jar:shaded6:5.1.0:compile
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-empi:jar:5.1.0:compile -- module hapi.fhir.jpaserver.empi (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-testpage-overlay:war:5.1.0:provided
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-testpage-overlay:jar:classes:5.1.0:compile -- module hapi.fhir.testpage.overlay (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-test-utilities:jar:5.1.0:test -- module hapi.fhir.test.utilities (auto)

if that helps

JoeMcCaffrey commented 3 years ago

I can reproduce and setting the reuse_cached_search_results_millis to 0 seems to fix it

camerondavison commented 3 years ago

given that this can be reproduced should did I file this in the correct repo?

JoeMcCaffrey commented 3 years ago

I think you can submit a pull request with the default being 0. I'm not a maintainer tho..

camerondavison commented 3 years ago

To me this is a bug in the core code. Setting it to 0 is a work around. We should not be able to ever get results from another partition

jtheory commented 3 years ago

I've been struggling with the same bug (and a few other nearby ones: I started a topic on chat.fhir.org); unfortunately, setting reuse_cached_search_results_millis to 0 isn't fixing it for me.

I'll attach a sequence I'm testing with -- this is a fresh database, so it's not a caching issue. See attached file: wrong_tenant_can_read.txt

A simple ?_id= returns the resource from a different partition, whereas referring to the resource by ID directly respects the boundary.

I've spent a few hours in the debugger, at this point, and have enabled DB query logging. The query that runs simply doesn't filter on partition:

hapi-fhir-postgres            | 2020-12-02 12:52:22.878 UTC [33] LOG:  execute <unnamed>: SELECT RES_ID FROM ( SELECT t0.RES_ID FROM HFJ_RESOURCE t0 WHERE (((t0.RES_TYPE = $1) AND (t0.RES_DELETED_AT IS NULL)) AND (t0.RES_ID = $2)) )  AS RES_ID limit $3
hapi-fhir-postgres            | 2020-12-02 12:52:22.878 UTC [33] DETAIL:  parameters: $1 = 'Patient', $2 = '1', $3 = '500'

...
fetch the row in HFJ_SEARCH where the search status is stored
then fetch the resource, selecting the partition but not filtering on it:

hapi-fhir-postgres            | 2020-12-02 12:52:22.893 UTC [34] LOG:  execute <unnamed>: select resourcese0_.PID as pid1_0_, resourcese0_.RES_DELETED_AT as res_dele2_0_, resourcese0_.RES_ENCODING as res_enco3_0_, resourcese0_.RES_VERSION as res_vers4_0_, resourcese0_.FORCED_PID as forced_p5_0_, resourcese0_.HAS_TAGS as has_tags6_0_, resourcese0_.PARTITION_ID as partitio7_0_, resourcese0_.PROV_REQUEST_ID as prov_req8_0_, resourcese0_.PROV_SOURCE_URI as prov_sou9_0_, resourcese0_.RES_PUBLISHED as res_pub10_0_, resourcese0_.RES_TEXT as res_tex11_0_, resourcese0_.RES_ID as res_id12_0_, resourcese0_.RES_TYPE as res_typ13_0_, resourcese0_.RES_VER as res_ver14_0_, resourcese0_.RES_UPDATED as res_upd15_0_ from ( SELECT h.pid               as pid,                           h.res_id            as res_id,                        h.res_type          as res_type,                      h.res_version       as res_version,                   h.res_ver           as res_ver,                       h.has_tags          as has_tags,                      h.res_deleted_at    as res_deleted_at,                h.res_published     as res_published,                 h.res_updated       as res_updated,                   h.res_text          as res_text,                      h.res_encoding      as res_encoding,                  h.PARTITION_ID      as PARTITION_ID,                  p.SOURCE_URI        as PROV_SOURCE_URI,               p.REQUEST_ID        as PROV_REQUEST_ID,               f.forced_id         as FORCED_PID      FROM HFJ_RES_VER h     LEFT OUTER JOIN HFJ_FORCED_ID f ON f.resource_pid = h.res_id     LEFT OUTER JOIN HFJ_RES_VER_PROV p ON p.res_ver_pid = h.pid     INNER JOIN HFJ_RESOURCE r       ON r.res_id = h.res_id and r.res_ver = h.res_ver ) resourcese0_ where resourcese0_.RES_ID in ($1)

wrong_tenant_can_read.txt

jtheory commented 3 years ago

This issue can be closed. :partying_face:

@jamesagnew fixed this bug in hapi-fhir core.

jamesagnew commented 3 years ago

@camerondavison can you confirm that your issue is no longer reproducible against latest 3.2.0-SNAPSHOT / git master?

camerondavison commented 3 years ago

I will work on this today.

camerondavison commented 3 years ago

I am assuming that you mean 5.2.0-SNAPSHOT? I am updating this https://github.com/hapifhir/hapi-fhir-jpaserver-starter/blob/329a7f3293cf3780c589f81e9ad853aab6a90e12/pom.xml#L17 to that

camerondavison commented 3 years ago

@jamesagnew made the change that I mentioned above to get the 5.2.0-SNAPSHOT

[INFO]    ca.uhn.hapi.fhir:hapi-fhir-base:jar:5.2.0-SNAPSHOT:compile -- module hapi.fhir.base (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-base:jar:5.2.0-SNAPSHOT:compile -- module hapi.fhir.jpaserver.base (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-client:jar:5.2.0-SNAPSHOT:compile -- module hapi.fhir.client (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-server:jar:5.2.0-SNAPSHOT:compile -- module hapi.fhir.server (auto)
[INFO]    ca.uhn.hapi.fhir:org.hl7.fhir.utilities:jar:5.1.19:compile -- module org.hl7.fhir.utilities (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-server-empi:jar:5.2.0-SNAPSHOT:compile -- module hapi.fhir.server.empi (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-subscription:jar:5.2.0-SNAPSHOT:compile -- module hapi.fhir.jpaserver.subscription (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-api:jar:5.2.0-SNAPSHOT:compile -- module hapi.fhir.jpaserver.api (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-searchparam:jar:5.2.0-SNAPSHOT:compile -- module hapi.fhir.jpaserver.searchparam (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-jpaserver-model:jar:5.2.0-SNAPSHOT:compile -- module hapi.fhir.jpaserver.model (auto)
[INFO]    ca.uhn.hapi.fhir:hapi-fhir-validation:jar:5.2.0-SNAPSHOT:compile -- module hapi.fhir.validation (auto)

Then ran

mvn jetty:run

and the curls that I have above.

$ curl -s http://localhost:8080/fhir/PARTITION-456/Patient | jq '.entry[].fullUrl'
"http://localhost:8080/fhir/PARTITION-456/Patient/pid-PARTITION-456"

$ curl -s http://localhost:8080/fhir/PARTITION-123/Patient | jq '.entry[].fullUrl'
"http://localhost:8080/fhir/PARTITION-123/Patient/pid-PARTITION-456"

Same problem for me.

Also same problem that @jtheory has.

$ curl -s 'http://localhost:8080/fhir/PARTITION-456/Patient?_id=pid-PARTITION-456' | jq '.entry[].fullUrl'
"http://localhost:8080/fhir/PARTITION-456/Patient/pid-PARTITION-456"

$ curl -s 'http://localhost:8080/fhir/PARTITION-123/Patient?_id=pid-PARTITION-456' | jq '.entry[].fullUrl'
"http://localhost:8080/fhir/PARTITION-123/Patient/pid-PARTITION-456"

Maybe I did not get the correct snapshot?

❯ for f in $(ls ~/.m2/repository/ca/uhn/hapi/fhir/*/*-SNAPSHOT/*.jar.sha1); do echo -n "$(basename $f) = "; cat $f; echo; done
hapi-fhir-base-5.2.0-20201117.124739-34.jar.sha1 = afe536d240df09f6152dc3d972469f4637489f1c
hapi-fhir-client-5.2.0-20201117.124808-32.jar.sha1 = a5c7958fda34faf71270aebeca72faacbe66680f
hapi-fhir-converter-5.2.0-20201117.125323-30.jar.sha1 = d4442e3f925713dafd032a201ac3f7b03db94646
hapi-fhir-elasticsearch-6-5.2.0-20201117.125535-30-shaded6.jar.sha1 = 0ead1b7d8df39529248cc698094388faf674f36f
hapi-fhir-jpaserver-api-5.2.0-20201117.125439-30.jar.sha1 = 943a0656e126563c3eb714bf6a0c08f6e8211f3b
hapi-fhir-jpaserver-base-5.2.0-20201117.125618-33.jar.sha1 = a00780a3edcc0cf76aca535d409594b364099198
hapi-fhir-jpaserver-batch-5.2.0-20201117.125521-30.jar.sha1 = cc6c1b562b11ba8dbbf6808077a67a2e0f6c2620
hapi-fhir-jpaserver-empi-5.2.0-20201117.125735-30.jar.sha1 = ebbd059cb93e45f7aade47bc935e9ad5261d46d6
hapi-fhir-jpaserver-model-5.2.0-20201117.125400-30.jar.sha1 = 9ccbc182f467b7956c3499ea33388bce5f893932
hapi-fhir-jpaserver-searchparam-5.2.0-20201117.125411-30.jar.sha1 = 6d11629b811a02fb467ecebe259c197f2fd8a0ad
hapi-fhir-jpaserver-subscription-5.2.0-20201117.125451-30.jar.sha1 = b0366da6e8b51b304662eed0541f9c52babc29e6
hapi-fhir-server-empi-5.2.0-20201117.125501-30.jar.sha1 = ac566f0ec3841b41a1202a8f127ad7cac35e81cf
hapi-fhir-server-5.2.0-20201117.124752-32.jar.sha1 = 39c550b3fbf24e3809c2ce40a5a963edbfddc14f
hapi-fhir-structures-dstu2-5.2.0-20201117.125251-30.jar.sha1 = 98913784e6dec06b859b0c15e361fbc20ec3aa54
hapi-fhir-structures-dstu3-5.2.0-20201117.124904-32.jar.sha1 = 55999b5eedf4a258ea48a90a92a2c7b7da162d89
hapi-fhir-structures-hl7org-dstu2-5.2.0-20201117.125055-31.jar.sha1 = 9f8a17edda37120da9e9414643a0750b134d549a
hapi-fhir-structures-r4-5.2.0-20201117.125022-31.jar.sha1 = 9c667e299b83210065b753dc8d899f291e0206fe
hapi-fhir-structures-r5-5.2.0-20201117.125203-30.jar.sha1 = 30a03c613b7e00f4c79460d0a6bb80eebd125050
hapi-fhir-test-utilities-5.2.0-20201117.124815-36.jar.sha1 = 1553566136f6a100360f310e2c741004aa0f35af
hapi-fhir-testpage-overlay-5.2.0-20201117.125638-30-classes.jar.sha1 = 800b710694912826f3eb3117e00a9d2e316fc97a
hapi-fhir-validation-resources-dstu2-5.2.0-20201117.125031-31.jar.sha1 = 0d1de261799291412d2886b4233665c027929e37
hapi-fhir-validation-resources-dstu3-5.2.0-20201117.124759-32.jar.sha1 = 11319b82c790e5892dbb94f631f88f7909f33ff9
hapi-fhir-validation-resources-r4-5.2.0-20201117.124914-32.jar.sha1 = 0c73e7bbee90f25b160dd1e29aaddde0f9639ba3
hapi-fhir-validation-resources-r5-5.2.0-20201117.125102-31.jar.sha1 = 3fd1161d4ef2987348782ad90e8ead700502a9b1
hapi-fhir-validation-5.2.0-20201117.125334-30.jar.sha1 = 75836aef1c02b3072ddc2a5961c7d6176d8532a4
jamesagnew commented 3 years ago

Sorry, no... typo on my part :(

5.3.0-SNAPSHOT is the version with this fix, that's the latest build on the 5.3.0 release train.

camerondavison commented 3 years ago

ah. i should have seen that too. looks better 2020-12-02

❯ for f in $(ls ~/.m2/repository/ca/uhn/hapi/fhir/*/*5.3.0*-SNAPSHOT/*.jar.sha1); do echo -n "$(basename $f) = "; cat $f; echo; done
hapi-fhir-base-5.3.0-20201202.112503-8.jar.sha1 = 68fecda6e7cc183397a24232ede05121d83f48fd
hapi-fhir-client-5.3.0-20201202.112619-8.jar.sha1 = 7b734773021faf46f4b723427ec886fdc44232a5
hapi-fhir-converter-5.3.0-20201202.113252-7.jar.sha1 = cb1eebb57e23c84d74b81e31de59bb68d2370d6d
hapi-fhir-elasticsearch-6-5.3.0-20201202.113458-7-shaded6.jar.sha1 = 74fc36012bbb39c66ceb1893cf3f4a6478bf1add
hapi-fhir-jpaserver-api-5.3.0-20201202.113410-7.jar.sha1 = 298c373213c81c0b5df8ab0af530f5cd8d4d9103
hapi-fhir-jpaserver-base-5.3.0-20201202.113538-8.jar.sha1 = f5f9bfde869ba406478c567e52b4f975c7ef0e93
hapi-fhir-jpaserver-batch-5.3.0-20201202.113440-7.jar.sha1 = 80c0acb89f25fe2e07eb8f1efaa7e0f50d5ced59
hapi-fhir-jpaserver-empi-5.3.0-20201202.113702-7.jar.sha1 = 6e143f667e619db7275911c89d4bf0916a934691
hapi-fhir-jpaserver-model-5.3.0-20201202.113334-7.jar.sha1 = 1a15fb77f1bb048b7bb068b646a2b94ecd169dcf
hapi-fhir-jpaserver-searchparam-5.3.0-20201202.134451-8.jar.sha1 = 0ffb7b63d65a160ee5d9632e8bb7c6c215d23a21
hapi-fhir-jpaserver-subscription-5.3.0-20201202.113422-7.jar.sha1 = 404ccdc015ae65d05e15604dad5e317ef9d8135c
hapi-fhir-server-empi-5.3.0-20201202.113432-7.jar.sha1 = 6fff613f49629a0e020ab59799cfe8913d5e440b
hapi-fhir-server-5.3.0-20201202.112538-8.jar.sha1 = 66959922374b5a136166562c99918a1b545f148c
hapi-fhir-structures-dstu2-5.3.0-20201202.113215-7.jar.sha1 = e423266ffdb97832ed1f853a53d1bf616b690d4f
hapi-fhir-structures-dstu3-5.3.0-20201202.112728-8.jar.sha1 = 15042a656e90aada55687e824f562048db728216
hapi-fhir-structures-hl7org-dstu2-5.3.0-20201202.113008-7.jar.sha1 = 1830883feca153a7ca9c62f1bfc6b85c56f2a91b
hapi-fhir-structures-r4-5.3.0-20201202.112906-7.jar.sha1 = dd85fa253c1ede968f45c9f2abd64046dd62f1e8
hapi-fhir-structures-r5-5.3.0-20201202.113127-7.jar.sha1 = b4bf5d65e3524ec9e4027dced25013842c61c2a8
hapi-fhir-test-utilities-5.3.0-20201202.112631-8.jar.sha1 = bef420f0bfa6187dac3253b5254498af53e8f4a4
hapi-fhir-testpage-overlay-5.3.0-20201202.113546-7-classes.jar.sha1 = c9b071985034ca0edf0954dd26b54a6efa69c70a
hapi-fhir-validation-resources-dstu2-5.3.0-20201202.112920-7.jar.sha1 = e38219ffd22d94042b61c574f5ea9f541147e3c8
hapi-fhir-validation-resources-dstu3-5.3.0-20201202.112554-8.jar.sha1 = e9c4a552ae3e694928b1faabd1a9d91f77d44638
hapi-fhir-validation-resources-r4-5.3.0-20201202.112741-7.jar.sha1 = db53659c89f155f25f604614c2e7365ee69a2817
hapi-fhir-validation-resources-r5-5.3.0-20201202.113018-7.jar.sha1 = 9b8758b3bcd3701ff63de398d5777643b83490f8
hapi-fhir-validation-5.3.0-20201202.113303-7.jar.sha1 = d35ceda7c0df48e5406dc1924401e073332762c6

started from a clean slate - both still broken

$ curl -s http://localhost:8080/fhir/PARTITION-123/Patient | jq '.entry[].fullUrl'
"http://localhost:8080/fhir/PARTITION-123/Patient/pid-PARTITION-123"

$ curl -s http://localhost:8080/fhir/PARTITION-456/Patient | jq '.entry[].fullUrl'
"http://localhost:8080/fhir/PARTITION-456/Patient/pid-PARTITION-123"

$ curl -s 'http://localhost:8080/fhir/PARTITION-456/Patient?_id=pid-PARTITION-456' | jq '.entry[].fullUrl'
"http://localhost:8080/fhir/PARTITION-456/Patient/pid-PARTITION-456"

$ curl -s 'http://localhost:8080/fhir/PARTITION-123/Patient?_id=pid-PARTITION-456' | jq '.entry[].fullUrl'
"http://localhost:8080/fhir/PARTITION-123/Patient/pid-PARTITION-456"
camerondavison commented 3 years ago

looks like maybe the snapshot was 2 commits earlier

$ unzip -p ~/.m2/repository/ca/uhn/hapi/fhir/hapi-fhir-base/5.3.0-SNAPSHOT/hapi-fhir-base-5.3.0-20201202.112503-8.jar ca/uhn/fhir/hapi-fhir-base-build.properties
#Created by build system. Do not modify
#Wed Dec 02 06:24:34 EST 2020
hapifhir.buildnumber=6e72ee8f6bf8568c1d46cfbbf052f8d1d885a752
name=HAPI FHIR - Core Library
hapifhir.version=5.3.0-SNAPSHOT
hapifhir.timestamp=2020-12-02T06\:24\:34.285-05\:00
jamesagnew commented 3 years ago

@camerondavison Thanks for testing.

Oh shoot. This looks like it's an issue with the query cache actually, not the SearchBuilder.

Sorry I didn't realize this before - I actually don't think the previously mentioned fix will cover this use case. Work continues... Shouldn't be hard to fix at least...