Server Side ETAG no longer being returned 3.1.0

[Chrisjobling]

After upgrading HapiFhir to version 3 from 2, Etags from the server are no longer automatically being returned. The setETagSupport() seems to have no impact. Is there any advice as to get the server to respond with the Etags again
Thanks

[jamesagnew]

Can you provide a bit more detail about what you are doing? ETags look ok to me (note the 3rd last header below)

 curl -v http://fhirtest.uhn.ca/baseDstu3/Patient/191025                                                      0 < 06:31:15
*   Trying 34.196.9.98...
* TCP_NODELAY set
* Connected to fhirtest.uhn.ca (34.196.9.98) port 80 (#0)
> GET /baseDstu3/Patient/191025 HTTP/1.1
> Host: fhirtest.uhn.ca
> User-Agent: curl/7.55.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx/1.10.3 (Ubuntu)
< Date: Wed, 20 Dec 2017 11:31:15 GMT
< Content-Type: application/fhir+json;charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< X-Powered-By: HAPI FHIR 3.1.0 REST Server (FHIR Server; FHIR 3.0.1/DSTU3)
< ETag: W/"9"
< Last-Modified: Fri, 15 Dec 2017 06:34:10 GMT
< Location: http://fhirtest.uhn.ca/baseDstu3/Patient/191025/_history/9
< 
{
  "resourceType": "Patient",
  "id": "191025",
  "meta": {
    "versionId": "9",
    "lastUpdated": "2017-12-15T01:34:10.319-05:00"
  },
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><div class=\"hapiHeaderText\">Keira1</div><table class=\"hapiPropertyTable\"><tbody><tr><td>Identifier</td><td>12345</td></tr></tbody></table></div>"
  },
  "identifier": [

[Chrisjobling]

We have a server implementation and are running automated tests against this implementation. A simple test example is "Read a patients single appointment" where previously an Etag was returned upon the read. I am setting the meta version ID of the appointment and ever since the upgrade from version 2 to 3 the Etag is no longer being returned. I am just wondering if it is to do with the Type changes from the upgrade or if there is something that needs to be added to respond with the Etags. I have read the documentation but am currently unable to get it included in the response.

Example response:

HTTP/1.1 200
Cache-Control: no-store
X-Powered-By: HAPI FHIR 3.0.0 REST Server (FHIR Server; FHIR 3.0.1/DSTU3)
Last-Modified: Wed, 20 Dec 2017 12:25:24 GMT
Location: "http://ans-a:19191/fhir/Appointment/1"
Content-Type: application/json+fhir;charset=UTF-8
Date: Wed, 20 Dec 2017 12:25:24 GMT
Content-Length: 1290

{"resourceType":"Appointment","id":"1","meta":{"versionId":"1","lastUpdated":"2017-12-20T12:25:24.000+00:00",

Any help would be appriciated
Thanks

[Chrisjobling]

HTTP/1.1 200
Cache-Control: no-cache, no-store
Expires: 0
Pragma: no-cache
X-Powered-By: HAPI FHIR 3.0.0 REST Server (FHIR Server; FHIR 1.0.2/DSTU2)
ETag: W/"1469444400000"
Content-Location: http://ans-a357:19191/fhir/Patient/1/_history/1469444400000
Last-Modified: Mon, 25 Jul 2016 11:00:00 GMT
Location: http://ans-a357:19191/fhir/Patient/1/_history/1469444400000
Content-Type: application/json+fhir;charset=UTF-8
Date: Wed, 20 Dec 2017 15:57:05 GMT
Content-Length: 1198

Just for reference this is the response when running the version with FHIR 1.0.2/DSTU2.

[jamesagnew]

Hmm. Would you be able to put a breakpoint here to see whether it's trying to add it?

https://github.com/jamesagnew/hapi-fhir/blob/master/hapi-fhir-server/src/main/java/ca/uhn/fhir/rest/server/RestfulServerUtils.java#L614

[haydenanswer]

Just to update you on this issue...

The line you suggested for the breakpoint above revealed that fullId.hasVersionIdPart() was false.

Now, in addition to moving from 2.x to 3.0.0, we also updated our server implementation from DSTU2 to STU3.

It seems that the DSTU2 structures and STU3 structures differ when setting the Metadata VersionId.

For example, in our implementation we had the following:

resource.getMeta().setVersionId(versionId);

In the DSTU2 structures, the call to getMeta() returns an IBaseMetaType, the implementation of which is contained within the resource . The implementation of setVersionId actually updates the id on the BaseResource (making the call to fullId.hasVersionIdPart() == true)

In contrast, in the STU3 structures the call to getMeta() returns a Meta (which is entirely seperate to the BaseResource).

Our solution so far has been to just set the BaseResource Id VersionId in addition to setting the BaseResource Meta VersionId - this feels a little hacky however.

[jamesagnew]

Ah, that makes sense. I'll update to look at the resource getMeta() version if the ID itself doesn't have one. Thanks!