responses use constant ETag and cache across job IDs (stale/wrong results)

[johngrimes]

Summary

$job responses return a constant ETag and are cached across different job IDs at the public demo endpoint, causing stale/wrong responses. This violates the expected ETag-based caching semantics and makes it appear as if job IDs are reused.

Environment

• Public endpoint: https://demo.pathling.app/fhir/$job?id=...
• Origin (via port-forward): kubectl -n demo port-forward svc/pathling-fhir 18080:8080

Evidence

Origin headers (port-forward)

Different job IDs and response bodies all return the same ETag:

GET http://127.0.0.1:18080/fhir/$job?id=beee6fff-94fd-4f84-b807-9ce2f80d7b84  -> 200, ETag: W/"mjavzazy"
GET http://127.0.0.1:18080/fhir/$job?id=2c8eb242-b4e3-4b3e-a23b-71202fea798c  -> 200, ETag: W/"mjavzazy"
GET http://127.0.0.1:18080/fhir/$job?id=eb9c0823-b584-4bdf-8356-b4dd78b8912a  -> 400, ETag: W/"mjavzazy"
GET http://127.0.0.1:18080/fhir/$job?id=904c5f83-7eee-4117-9262-d7f99da8613d  -> 500, ETag: W/"mjavzazy"

ETag does not change even when the body/status differs.

Public endpoint caching across job IDs

The public endpoint returns the same cached body for different job IDs:

GET https://demo.pathling.app/fhir/$job?id=beee6fff-94fd-4f84-b807-9ce2f80d7b84
  -> HTTP 200, ETag W/"mjavzazy", sha256=8861e71fe8f639ec525d6795f9cc7dfd5abd6886fe496be43de8f09639039a74
GET https://demo.pathling.app/fhir/$job?id=904c5f83-7eee-4117-9262-d7f99da8613d
  -> HTTP 200, ETag W/"mjavzazy", sha256=8861e71fe8f639ec525d6795f9cc7dfd5abd6886fe496be43de8f09639039a74 (identical body)

But the origin for 904c... returns 500 OperationOutcome (Unexpected error occurred).

Expected

• ETag should change when the underlying response changes (per job), and remain stable only when the underlying data does not change.
• Caching must vary by job ID (query string), so different job IDs never serve each other’s responses.
• Job IDs must remain unique and not appear to be reused due to caching.

Impact

Clients polling $job can receive incorrect or stale data, which breaks the async status workflow.