Triggers a manual schema drift detection run for the supplied (organizationId,
integrationId). integrationId is required. organizationId is optional and
defaults to the organization of the authenticated session, which is also the
organization the EDIT_DATA_CATALOGS permission is asserted against when the
field is omitted.
The endpoint is asynchronous when the LaunchDarkly flag
data-fabric-schema-drift-async-enabled is ON for the requesting organization
(intended LD default): the cooldown slot is claimed synchronously and the
detection work itself runs in the background on a bounded executor. A successful
dispatch returns 202 Accepted with no body; the final detection outcome is
observed via the existing integration status events (CONNECTED / FAILED) rather
than the HTTP response.
When the flag is OFF (panic revert per-org or globally, OR when LaunchDarkly is
unreachable / the flag does not exist), the endpoint reverts to the previous
synchronous behaviour and returns 204 No Content after the detection completes.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Accepted — the detection run has been dispatched to the background executor.
No response body.
No Content — returned when the LaunchDarkly flag
data-fabric-schema-drift-async-enabled is OFF for the requesting
organization (panic revert, or LaunchDarkly is unreachable / the flag does
not exist); the detection completed synchronously.
Bad Request — rejected at the request boundary, either because the body is
absent (message conversion) or because it omits the required integrationId
(bean validation). No detection work runs and no cooldown slot is claimed.
The body is Spring's default validation problem detail rather than
ErrorEnvelope.
Too Many Requests — a previous detection for this (organizationId,
integrationId) pair is still in progress or finished within the cooldown
window. Retry after the cooldown elapses.
Service Unavailable — the schema drift executor is saturated (all worker
threads busy and queue full). Retry after a short back-off. Sustained
occurrences indicate the pool needs tuning via
com.formstack.data-catalog.schema-drift-detection.async.max-pool-size
or .queue-capacity. The cooldown row claimed by the request is released
before the 503 is returned, so the retry is not blocked by cooldown.