Data problem

StandardError

[Medplum::CareExtender] Practitioner update for CareExtender/714 refused by Medplum (HTTP 410)

ZoomUserSyncToCareExtenderJob@zoom_users_sync5 events · 0 users first seen 6 d agolast seen 45 min ago

In one line

Medplum answered HTTP 410 (Gone) when we updated the Practitioner linked to CareExtender 1250 on staging. The stored medplum_practitioner_id most likely points to a Practitioner that no longer exists, probably after a staging Medplum reset or cleanup.

Checked against the code

What happened

The create action calls append_opc_roles_to_existing, which calls sync_medplum_practitioner. That finds an existing medplum_practitioner_id and patches it through Medplum::Writer.
Medplum rejected the patch with a 4xx that retrying cannot fix (410). The code then calls Bugsnag.notify on purpose, with a warning severity.
There were 15 events in 6 days, all on staging and with the same id in the message. This points to one stale record being re-saved, not a code regression.
The sync is wrapped in a rescue, so the provider save is not blocked.

What to do next

Query Shows the stored Practitioner id, which you can then look up in staging Medplum to confirm it was deleted.
```
SELECT id, medplum_practitioner_id, updated_at FROM care_extenders WHERE id = 1250;
```
Check In the staging Medplum UI or API, GET Practitioner/<medplum_practitioner_id> to confirm it returns 410 or 404. If it does, clear the stale link on CareExtender 1250 so the next save re-adopts or recreates the Practitioner.

Queries are shown, never run. Check them before using them on production.

Ask a follow-up

Continues the same session, so it still remembers the error and the code it read.

Analysed 1 h ago · claude-sonnet-5-5 · $0.03