Re-implement plan execution monitoring via CouchDB using a provider via Plan API

[shefalijoshi]

Can we please file a followup to pull out this legacy code and re-implement using the new API?

Originally posted by @akhenry in #8427 (comment)

[akhenry]

Please also address the following general issues in the initial implementation of plan execution monitoring -

Issue 1

PlanAPI.getExecutionStatus deregisters its abort controller before the request completes

PlanAPI.getExecutionStatus is not async and does not await the provider call, so its finally block runs synchronously at return — before the returned promise settles:

openmct/src/api/plan/PlanAPI.js

Lines 109 to 133 in e1a65cd

	getExecutionStatus(domainObject) {
	const provider = this.#findExecutionStatusEvaluator(domainObject);
	if (!provider || !provider.getExecutionStatus) {
	return undefined;
	}
	const abortController = new AbortController();
	const options = { signal: abortController.signal };
	this.requestAbortControllers.add(abortController);
	try {
	return provider.getExecutionStatus(domainObject, options);
	} catch (error) {
	if (error.name !== 'AbortError') {
	this._openmct.notifications.error(
	'Error requesting execution monitoring data, see console for details'
	);
	}
	throw new Error(error);
	} finally {
	this.requestAbortControllers.delete(abortController);
	}
	}

Two consequences:

1. abortAllRequests() is a no-op for plan requests. The controller is removed from requestAbortControllers while the request is still in flight, so the set is always empty by the time anything iterates it. That makes the call added at ApplicationRouter.js#L325 dead code — navigating away never cancels an in-flight execution status request.

2. The catch never runs. A rejected promise won't be caught by a synchronous catch, so the "Error requesting execution monitoring data" notification never fires and provider rejections surface as unhandled.

Expected

Match the established pattern in TelemetryAPI.request, which is async and awaits inside the try so the controller stays registered for the lifetime of the request:

openmct/src/api/telemetry/TelemetryAPI.js

Lines 470 to 513 in e1a65cd

	async request(domainObject) {
	if (this.noRequestProviderForAllObjects || domainObject.type === 'unknown') {
	return [];
	}
	if (arguments.length === 1) {
	arguments.length = 2;
	arguments[1] = {};
	}
	const abortController = new AbortController();
	arguments[1].signal = abortController.signal;
	this.requestAbortControllers.add(abortController);
	this.standardizeRequestOptions(arguments[1]);
	const provider = this.findRequestProvider.apply(this, arguments);
	if (!provider) {
	this.requestAbortControllers.delete(abortController);
	return this.#handleMissingRequestProvider(domainObject);
	}
	arguments[1] = await this.applyRequestInterceptors(domainObject, arguments[1]);
	try {
	const telemetry = await provider.request(...arguments);
	if (!this.#hasReturnedFirstData) {
	this.#hasReturnedFirstData = true;
	performance.mark('firstHistoricalDataReturned');
	}
	return telemetry;
	} catch (error) {
	if (error.name !== 'AbortError') {
	this.openmct.notifications.error(
	'Error requesting telemetry data, see console for details'
	);
	console.error(error);
	}
	throw new Error(error);
	} finally {
	this.requestAbortControllers.delete(abortController);
	}
	}

Fix

Make getExecutionStatus async and return await provider.getExecutionStatus(domainObject, options).

Affected

Introduced in #8427. Also present on gold via the cherry-pick in #8441.

Issue 2

Concurrent getPlanExecutionMonitoringStatus() calls leak execution status subscriptions

getPlanExecutionMonitoringStatus in TimelineViewLayout.vue is async and stores only the most recent unsubscribe function:

openmct/src/plugins/timeline/TimelineViewLayout.vue

Line 565 in e1a65cd

async function getPlanExecutionMonitoringStatus() {

The assignment at L578 overwrites any previous value, but PlanAPI.subscribeForExecutionStatus refcounts callbacks per keyString and returns a distinct unsubscribe per caller:

openmct/src/api/plan/PlanAPI.js

Lines 148 to 184 in e1a65cd

	subscribeForExecutionStatus(domainObject, callback) {
	const provider = this.#findExecutionStatusEvaluator(domainObject);
	if (!provider || !provider.subscribeForExecutionStatus) {
	return () => {};
	}
	if (!this.executionMonitoringSubscribeCache) {
	this.executionMonitoringSubscribeCache = {};
	}
	const keyString = makeKeyString(domainObject.identifier);
	let subscriber = this.executionMonitoringSubscribeCache[keyString];
	if (!subscriber) {
	subscriber = this.executionMonitoringSubscribeCache[keyString] = {
	callbacks: [callback]
	};
	subscriber.unsubscribe = provider.subscribeForExecutionStatus(domainObject, function (value) {
	subscriber.callbacks.forEach(function (cb) {
	cb(value);
	});
	});
	} else {
	subscriber.callbacks.push(callback);
	}
	return function unsubscribe() {
	subscriber.callbacks = subscriber.callbacks.filter(function (cb) {
	return cb !== callback;
	});
	if (subscriber.callbacks.length === 0) {
	subscriber.unsubscribe();
	delete this.executionMonitoringSubscribeCache[keyString];
	}
	}.bind(this);
	}

So when two calls overlap, both push a callback into subscriber.callbacks, only the second unsubscribe is retained, and on teardown callbacks.length never reaches 0. The provider subscription stays open and the orphaned callback keeps a closure over the destroyed component alive.

Reproduction

getPlanExecutionMonitoringStatus() is invoked from three places — onMounted, checkAddedForPlan, and checkRemovedForPlan — with checkAddedForPlan firing once per composition child from addItem.

1. Open a Time Strip containing two or more plans, with an execution status provider registered.
2. Both plans' checkAddedForPlan calls are in flight concurrently; each subscribes.
3. Navigate away. The provider subscription remains open, and status updates continue invoking a callback bound to the unmounted component.

On master the onMounted call itself is not part of the race — compositionCollection.load() is a floating promise started in setup(), so onMounted runs first with plans still empty and returns early. Two plans are therefore the minimum.

Note for gold: the cherry-pick in #8441 targets an Options API version of this component whose mounted() runs after await this.composition.load(). There the mounted() call overlaps the per-plan calls, so a single plan is enough to trigger the leak.

Suggested fix

Either guard against overlapping invocations in the component (track the in-flight request and discard stale results), or make subscribeForExecutionStatus tolerate a repeat subscriber from the same consumer. The component-side guard is probably the narrower change.

Affected

Introduced in #8427. Also present on gold via #8441, with a wider trigger as described above.