SubscriptionValidationResponse type

Determines what to do with an incoming context

  • true/accept: Allow the incoming context through, and any subsequent/queued data that belongs to it - false/deny: Deny the incoming context, if no context has been accepted, then queue data until one is - accept_and_terminate: Allow the incoming context, then deny further data, flush and shut down the node this is useful for cleanly terminating outputs when the context is empty - deny_and_queue: Deny the incoming context, and revert to the original queueing behaviour as if no context has been accepted this is useful when switching from one full context to another, avoiding any "in-between" - deny_and_drop: Deny the incoming context, drop any currently queued data, and drop any further data that might be received this is useful if you have a lot of setup on start-up and would prefer not to queue data while waiting for that to take place

Denying a SHRUNK context (one source of several having gone away) is a deliberate and often correct choice: it avoids churning a node whose every context change is expensive, such as a foreach over many streams whose children restart on each change. But a denied context is not passed on to the node’s internals, so anything they are holding for the departed stream is held until a context IS accepted. On the hardware composes (hardwareAcceleration: "quadra" | "nvidia") what is held is a card buffer carrying the upstream conversion’s in-flight credit, and holding it stalls that conversion’s flush permanently — the graph stops without an error rather than dropping frames. If the graph can produce a shrunk context (more compose parts than distinct sources, or sources of different lengths), accept it.

Signature:

export type SubscriptionValidationResponse = true | false | "accept" | "deny" | "accept_and_terminate" | "deny_and_queue" | "deny_and_drop";