Skip to content

Optionally retry requests OBS rejects with NotReady #27

Description

@Agash

OBS answers NotReady (207) while it is mid scene-collection change or shutting down. The protocol documents the remedy itself:

This usually occurs during OBS scene collection change or exit. Requests may be tried again after a delay if this code is given.

The connection stays up and identified through this, so a consumer sees ordinary request failures and has to hand-roll a retry to survive a scene collection switch.

NotReady is the only status whose description says to retry, so the policy stays narrow: no other code should be swept in.

Shape

Opt-in, off by default. Microsoft.Extensions.Resilience is already referenced and ObsWebSocketResilience already registers a named pipeline for reconnect, so this is a second pipeline rather than a bespoke loop. Polly types come in through that package; there is no direct Polly reference. It has to honour the caller's CancellationToken and the overall request timeout, and use the injected TimeProvider so FakeTimeProvider can drive the tests.

Bounded attempts and bounded delay: an OBS stuck in a bad state must fail, not spin.

Open question

Whether to apply it to every request or only to reads. A retried ToggleRecordPause is not the same request twice. Worth deciding before implementing — NotReady means the request was rejected rather than partially applied, so all requests are probably safe, but that should be confirmed against the request handler rather than assumed.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions