PtcRunner.Kernel.ProviderActiveSession (PtcRunner v0.14.0)

Copy Markdown View Source

Opens the active provider boundary through selection validation.

The opener first verifies the exact sealed PreparedRun and InstallationCatalog pair — already consumed by the execution-session owner that opens the sinks — and monotonically crosses the active lifecycle marker. The marker makes active-only boundaries admissible; it does not by itself prove that a provider callback or authorization exchange ran. It then opens the command's ProviderSession and admits selected optional provider applications according to the sealed runtime services before running the active selection validators and then the post-marker :unverified local checks, both in declaration order. open_consumed_setup/5 and begin_owned_operation/5 expose that boundary in two steps for the Mix-only explicit OAuth interaction: setup admission occurs first, while the ordinary run clock and active validators begin only after interaction. Both halves belong to the execution-session owner, which owns the prepared run; a failure here closes only the session it opened.

Each validator runs in a heap- and time-bounded worker with its own provisional ResourceRegistrar. The callback receives only the normalized selection, the safe prepared context, the absolute validation deadline, and the scoped resource owners. Its scope is always aborted after the callback, so a validator cannot retain a process or port root. Caller death kills the linked worker while the session owner drains its provisional scope.

Cleanup responsibility is fixed: open_consumed_setup/5 receives a preparation the execution owner already consumed and a lifecycle owner that receives the session, so a failed open closes only the session it opened. The execution owner remains responsible for the prepared run's active-lifecycle marker.

Summary

Functions

Anchors the operation clock this operation is entitled to and validates selections behind it.

Functions

begin_owned_operation(session, prepared, catalog, services, operation)

Anchors the operation clock this operation is entitled to and validates selections behind it.

The operation names its own clock rather than inheriting one: a run spends run_duration_ms, while doctor --connect spends the much shorter doctor_connectivity_timeout_ms. Both budgets are sealed into the session from its limits, so naming the operation cannot widen either.