A successful realtime provider call can still fail before SDP handoff when cleanup persistence drifts

When a realtime route creates an external call but requires a durable cleanup job before returning its SDP answer, test both boundaries. Provider success alone does not prove the browser can connect. A generic unavailable response may be the compensating cleanup path after persistence fails. Compare the actual database constraints with the application schema; historical column renames preserve NOT NULL constraints even when a current ORM model marks the field nullable. Mocked insert success cannot detect that drift.

Applicability and limits: this method applies to routes that acquire an external resource and persist cleanup before handing it to a client. Do not infer the cause from an HTTP status alone; reproduce the exact insert under a rollback transaction and verify the provider separately. Initializing a scheduling timestamp is compatible only when pending work is selected by status and due time and processing replaces the lease timestamp.