[BACK-4571] [BACK-4528] Remove summaries from CDC stream of the patients collection and remove summaries stream - #367
toddkazakov wants to merge 3 commits into
Conversation
The connector streamed the data service summary collection to the data.summary topic for the clinic-worker patient summary consumer. The platform data service now updates and deletes patient summaries in the clinic service directly from the upload postprocess work, and clinic-worker drops the consumer, so nothing reads the topic anymore.
ewollesen
left a comment
There was a problem hiding this comment.
Maybe these things are all fine, I'm not totally sure.
Are "internal" routes supposed to be in Gloo?
| upstream: | ||
| name: clinic | ||
| namespace: {{ .Release.Namespace }} | ||
| - matchers: |
There was a problem hiding this comment.
Claude seems to think you'll need a route for the summary update here:
The failure chain once platform PR 968 ships. The postprocess processor calls the clinic client's UpdatePatientSummary. The request goes to http://internal./v1/patients//summary as a POST. No clinic route matches, so Gloo hands it to blip. Blip's Express server has no handler there and returns 404. Platform's clinic client at platform/clinics/service.go:232 treats 404 as success, which is intentional for the case where the patient is not in any clinic. The work item completes, nothing is logged at error level, nothing retries. With the data.summary connector gone, clinic's stored cgm and bgm stats never change again.
I won't claim to 100% understand this, but here's what I do understand from this (let me know what I'm misunderstanding):
The /v1/patients/{id}/summary endpoint is available internally (internal to what? I guess the k8s cluster?), which is how clinic-worker calls it, but this PR adds platform as a caller of this endpoint. Its clinic client is configured using an external (external to what?) address for the clinic service, which is causing its requests to be routed through Gloo, which doesn't have a matching endpoint defined, causing the request to be routed to blip (as a fallback), which also doesn't have a handler, so blip returns 404. The original platform caller assumes that 404 is a patient not found, so the failure is quietly dropped, no log, no indicator that anything is wrong.
It's not clear to me how the routing differs between the clinic-worker and platform?
When would you choose one versus the other?
Summary updates are now handled in platform