[7269] bulk export history fails with client-assigned string IDs

[robcaruso]

Issue

Bulk export with _includeHistory=true fails to export history records for resources that have client-assigned string IDs (forced IDs). The export
completes successfully but history versions are missing from the output for any resources with client-assigned IDs.

Cause

When performing a bulk export with history enabled, the processHistoryResources() method was converting resource PIDs to their forced ID strings via
convertToStringIds() before querying for history. However, history records in the database are indexed by numeric PIDs, not forced IDs. This causes
the history query (IBulkDataExportHistoryHelper.fetchHistoryForResourceIds()) to return no results for resources with client-assigned IDs.

Fix

Modified ExpandResourceAndWriteBinaryStep.processHistoryResources() (line 225) to use numeric PIDs directly by calling
typePidJsonList.stream().map(TypedPidJson::getPid).toList() instead of convertToStringIds(). The bulk export history helper can work with PIDs
natively, making the forced ID conversion unnecessary and incorrect for history queries.

Added test testSystemBulkExportWithHistory_WithClientAssignedIds() that validates all history versions are exported for resources with forced IDs.

Closes #7296

[robogary]

Formatting check succeeded!

[jdar8]

Left a suggestion on the changelog. Other than that, looks good to me!

Requires a senior+ approval

[michaelabuckley]

problem: I don't trust this test. Can you show some Observations with a client assigned id connected to the Patient, and test this with Group export?

[michaelabuckley]

problem: this looks wrong. pids are our internal primary key which is a Long. Flattening these to a string will work for numeric ids, but not for client-assigned ids.

I think this call chain is broken. We do bulk-export in PID space, not FHIR-id space, for performance reasons. But the main IFhirResourceDao interface is all FHIR-id space. We can't use it unless we make a database round-trip to resolve pids back to FHIR-ids. see IIdHelperService.translatePidsToFhirResourceIds.

Alternatively, you could bypass IFhirResourceDao and talk to the PID-based layer. See this call in the history path -

hapi-fhir/hapi-fhir-jpaserver-base/src/main/java/ca/uhn/fhir/jpa/dao/BaseHapiFhirResourceDao.java

Lines 1387 to 1396 in 2d5d092

	return myPersistedJpaBundleProviderFactory.history(
	theRequest,
	myResourceName,
	entity.getResourceId(),
	theHistorySearchDateRangeParam.getLowerBoundAsInstant(),
	theHistorySearchDateRangeParam.getUpperBoundAsInstant(),
	theHistorySearchDateRangeParam.getOffset(),
	theHistorySearchDateRangeParam.getHistorySearchType(),
	requestPartitionId);
	});

The downside of that is you'll need to introduce a Mongo abstraction, and implement both sides.

[michaelabuckley]

If we have an upstream JIRA, we add that here.

Suggested change

	issue: 7296
	issue: 7296
	jira: SMILE-blah-blah