Class MeetingManager

Throws

RangeError when usageSilenceMs is given and is not a finite number of milliseconds above zero.

Throws

TypeError when usageSilenceMs is given and the run store has no updateWith.

Registers a provider under its name; a later provider with the same name replaces it.

The provider registered under name, if there is one.

The provider a send uses: the one named, or else the first registered provider that declares the platform.

Refuses new sends to the platform with platform_paused; runs already sent go on.

Takes new sends to the platform again.

Whether new sends to the platform are refused.

Adds a handler for every event the manager emits; the function returned removes it.

Sends a bot: answers the run an earlier send by the same owner with the same idempotency key made, checks the link against the platform, reserves the run's time, stores the run and schedules its dispatch (now, or at joinAt). A reservation that covers less than minReservationSeconds is released and the send refused. A limit the request leaves out, or gives as undefined, takes its default. A send whose job store fails after the run is stored rejects with that error; MeetingManager.reconcile then gives the run its job, so a send repeated with the same key answers a run that is dispatched.

Throws

RangeError when joinAt or a limit the request gives is not a finite number (a limit must also be zero or more); nothing is reserved.

Throws

Error when the manager's creation has a funding selector: a funded run is sent with MeetingManager.sendBotPrepared alone.

Sends a bot by recoverable creation, for a host that commits its own preparation (a consent record, for example) before any worker is sent for the run. Under the host's lock for the owner (creation.withOwnerLock), a send whose idempotency key an earlier send used answers that send's run, once that run's creation is finished when an interruption left it pending. A new send is checked as MeetingManager.sendBot checks one, admitted by the host (creation.admit) and written pending (creationPending, with context as its creationContext); then, in this order, its reservation is taken through the entitlement hook's reserveOnce by the run's id and written on the run with the run's limit cut to it, the host prepares the run (creation.prepare), its job is scheduled, the two fields are cleared and bot:requested is emitted. An interruption at any step leaves the run pending: a send repeated with the same key, or the next pass of the loop, resumes it with the context first given, and no job of a pending run is dispatched. A reservation refused, or one under minReservationSeconds, is released and the run is answered failed, with the refusal's reason (allowance for a short one). A creation still unfinished dispatchRetryMs after the run's join time, or after its request when that is later, ends crashed, unbilled, and its hold is released.

With creation.funding, the host's selector answers a new send's funding snapshot once, after admit and before anything is written, and the snapshot is written with the pending run: from then on the run is reserved, checked at its dispatch and while it runs, and settled from that snapshot alone. A send its key repeats selects nothing.

Throws

Error when the manager has no creation, the entitlement hook has no reserveOnce or the request has no idempotency key; when creation.funding is given and the manager has no dispatchGuard, the entitlement hook no checkRun, recover or finalize, or the run store no listFundingPending, before the selector is asked; when the selected snapshot does not fit the run (assertMeetingFundingChange) or expires before the run's join time plus its total limit, with nothing written; and when the run store does not keep creationPending and creationContext as written, after the run is ended crashed.

Throws

RangeError when joinAt or a limit the request gives is not a finite number (a limit must also be zero or more); nothing is written.

Runs a tick's two passes every second until stop(), apart from each other: the dispatches (after the creations an interruption left pending are finished), and the upkeep (the funded runs' checks, the limits, the kills, the purges and cleanups resumed, the funding cleanups resumed in the background, the eviction and a reconcile every minute). Apart, a dispatch a provider is slow to answer (a worker pulling its image) holds back no limit: a quiet stop monitor is still suspended and an armed kill still fires while it waits. Each pass runs one at a time, so a slow store does not stack passes on each other, except that a pass still running five intervals after it began is no longer waited for and the next one starts beside it: a pass held by a call that never answers (a command to a worker that froze) would otherwise stop every later one. A host with its own scheduler calls tick() itself.

Stops the loop start() began; a pass already running finishes.

One pass: the creations an interruption left pending finished, due jobs dispatched, then the upkeep (funded runs checked, limits enforced, kills issued, purges resumed, funding cleanups resumed in the background, a reconcile every minute). Each step runs even when an earlier one throws, so a dispatch that fails on one run never holds back the limits of the others (the stop monitor's suspension among them); the first error is thrown once the pass is over. The steps run in turn, so a dispatch that takes long holds this pass's limits back until it returns; start() runs the dispatches and the upkeep apart.

A provider's report, from the product's events route. Verified by the provider, parsed, deduplicated, applied.

The bot leaves; the run's data stays under its Keep. Before dispatch the run ends; during a dispatch the cancel becomes a leave.

The bot leaves and everything it took is deleted (the purge sequence). On a run that is over, done or failed before it joined, what is kept is deleted and the host's purge hooks run (a session's deletion). False for a run that does not exist.

Posts to the meeting's chat through the run's bot; false unless the run is in the call and its provider posts to chat.

A run sent from a page: the page is still there. A run that is over keeps its terminal row as it was written.

Adds a step to the purge sequence, as MeetingManagerConfig.purgeHooks does.

The run's row, or undefined when there is none.

The runs the filter selects, newest first, as the run store's IRunStore.list answers them.

Compares dispatched jobs with the providers' usage: a run whose container is gone is ended as crashed; an unfinished purge is resumed; what a provider's supplier measured for a run is recorded through the entitlement hook's recordSupplierUsage, when the hook has one. First, the supplier totals the hook refused before, kept in the stores' supplierUsageInbox, are handed to it again; then, with usageSilenceMs, each run gone silent for that long is ended at its last usage before any provider is asked, and a run whose container a provider reports gone ends at the total its usage reports gave. An answer about a run the provider was not asked about is ignored and logged. A run still waiting for its dispatch whose job is missing (a send whose job could not be stored) is given its job again, unless its creation is pending (its creation schedules the job), and one a cancel left without its job (the cancel's reason is on the run) is ended, so neither waits for ever holding its reservation; a waiting funded run whose funding settlement is written is not given its job. Before all of it, each dispatched funded run is checked against its own funding at recovery, and one refused is stopped. As in the limits, a run whose step throws holds back no other, and the first error is thrown at the end.

Whether a run takes transcript turns now: it is not behind the fence or over, and its capture has started or the capture interlock holds. The start is written on the run once the bot has answered startCapture, and the bot can send its first audio, and so a first final, before that answer; a turn from audio a provider passed on before the interlock held is dropped (the interlock does not rest on the provider alone). The transcript sink reads it too.

A turn the listen session wrote: a bot:transcript event, stored and forwarded, unless the run takes no turns now (MeetingManager.takesTurns: behind the fence or over, or before its capture can start) or its transcript is fenced.

The sink a listen session writes to for one run: the transcript store behind the fence, then the event above.