This has not reached production yet, so it has not caused a prod issue, but it may matter as we get closer to real migrations.
When org schema fields move, existing documents can retain the old field shape unless we explicitly migrate or mask responses.
Example:
advisory_location_require_credentials moved out of program_data and is now a top-level org field. If an existing document still has program_data.advisory_location_require_credentials, GET may return that stale nested field. A client using that GET response as the basis for a full PUT would then fail validation, because the current schema no longer allows that field inside program_data.
That makes cleanup the user/client’s responsibility: they have to manually remove stale fields before retrying the PUT.
Suggested follow-ups:
- Add migrations whenever org field locations/types change, including
$unset for old field paths.
- Consider applying the current response schema as an output mask before returning org objects, so GET responses do not include fields that current PUT validation rejects.
This has not reached production yet, so it has not caused a prod issue, but it may matter as we get closer to real migrations.
When org schema fields move, existing documents can retain the old field shape unless we explicitly migrate or mask responses.
Example:
advisory_location_require_credentialsmoved out ofprogram_dataand is now a top-level org field. If an existing document still hasprogram_data.advisory_location_require_credentials, GET may return that stale nested field. A client using that GET response as the basis for a full PUT would then fail validation, because the current schema no longer allows that field insideprogram_data.That makes cleanup the user/client’s responsibility: they have to manually remove stale fields before retrying the PUT.
Suggested follow-ups:
$unsetfor old field paths.