Querying by meta.source returns incorrect results after resource update

[BCvma]

Describe the bug Searching for resources with a specific meta.source does not reflect the current state of data if the value of this column has changed over time. Changing the meta.source of a resource to a new value and then querying for all resources with the old value returns both the resources which originally had the old value and all resources which currently have this value.

To Reproduce Steps to reproduce the behavior:

1. POST a resource to your local FHIR server (POST http://your-sever-url/fhir/Organization/)

   {
   "id": "1",
   "resourceType": "Organization",
   "meta": {
   "versionId": "1",
   "lastUpdated": "2024-06-07T14:44:38.194+02:00",
   "source": "some-source"
   },
   "active": true,
   "name": "Org 1"
   }

2. Update the new resource via PUT (PUT http://your-sever-url/fhir/Organization/1). You need to change more than just the source to reproduce it:

   {
   "id": "1",
   "resourceType": "Organization",
   "meta": {
   "versionId": "1",
   "lastUpdated": "2024-06-07T14:44:38.194+02:00",
   "source": "some-other-source"
   },
   "active": true,
   "name": "New fancy org name"
   }

3. Fetch the data filtering for a specific source (GET http://your-sever-url/fhir/Organization?_source=some-source). The result includes the organization you just updated, even though you are searching for the old source.

Expected behavior Only resources with the passed source should be returned by the FHIR server when querying without _history.

Environment:

• HAPI FHIR Version: 6.10.5
• OS: RHEL8

Additional context Debugging through the code, we observed the query:

SELECT top(?) t0.RES_ID FROM HFJ_RESOURCE t0 INNER JOIN HFJ_RES_VER_PROV t1 ON (t0.RES_ID = t1.RES_PID) WHERE (((t0.RES_TYPE = ?) AND (t0.RES_DELETED_AT IS NULL)) AND (t1.SOURCE_URI = ?))

It seems like the table HFJ_RES_VER_PROV is not being updated correctly when the source of a resource is updated.