You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When calling create/update, the request id is persisted but tables are limited to 16 characters which it not enough for an UUID. As a result the request id is not persisted correct and in our specific scenario it is causing problems as meta.source relies on requestId - See below. In general the cut-off is also a problem regarding tracking by the request id as the whole id is not persisted.
Our scenario:
Calling create/update for a resource. The requestId is an UUID(assigned by istio/envoy) and the UUID is returned in the meta.source with full length but only 16 characters is persisted.
Calling update with the response from the create/update call will contain a payload with the full UUID in meta.source but our update method fetches the persisted resource and in some scenarios we want to ensure only specific fields has been modified. That means the payload contains the full UUID in meta.source but the persisted resource has the cut-off requestId which is mapped to meta.source and causing meta.source not being equal.
hapifhir:
Method handleRequest in class RestFulServer assigns request id from request header X-Request-ID to RequestDetails.requestId. Later on the requestId is persisted in HFJ_RES_VER and HFJ_RES_VER_PROV but limited to 16 characters but the request id is an UUID which is cut-off when persisted.
RequestDetails:
RestfulServer.handleRequest
calls getOrCreateRequestId which will get id from either X-Request-ID or generate a randomAlphaNumeric - a 16 character id in that case.
Expected behavior
The X-Request-ID header is persisted in full length meaning the database should support at least UUID length and maybe longer to be more flexible?
Environment
HAPI FHIR Version: v. 6.10.5 (REQUEST_ID still limited to 16 characters on master branch)
The text was updated successfully, but these errors were encountered:
Describe the bug
When calling create/update, the request id is persisted but tables are limited to 16 characters which it not enough for an UUID. As a result the request id is not persisted correct and in our specific scenario it is causing problems as meta.source relies on requestId - See below. In general the cut-off is also a problem regarding tracking by the request id as the whole id is not persisted.
Our scenario:
hapifhir:
Method handleRequest in class RestFulServer assigns request id from request header X-Request-ID to RequestDetails.requestId. Later on the requestId is persisted in HFJ_RES_VER and HFJ_RES_VER_PROV but limited to 16 characters but the request id is an UUID which is cut-off when persisted.
RequestDetails:
RestfulServer.handleRequest
calls getOrCreateRequestId which will get id from either X-Request-ID or generate a randomAlphaNumeric - a 16 character id in that case.
Call stack for create (master branch):
BaseHapiFhirResourceDao.doCreateForPost
BaseHapiFhirResourceDao.doCreateForPostOrPut
BaseHapiFhirDao.updateEntity
BaseHapiFhirDao.createHistoryEntry
MetaUtil.populateResourceSource
Expected behavior
The X-Request-ID header is persisted in full length meaning the database should support at least UUID length and maybe longer to be more flexible?
Environment
HAPI FHIR Version: v. 6.10.5 (REQUEST_ID still limited to 16 characters on master branch)
The text was updated successfully, but these errors were encountered: