eyevinn-channel-engine 5.1.2 → 5.2.0

package/docs/design/mixing-muxed-demuxed-audio.md

@@ -0,0 +1,153 @@
+# Design note: mixing muxed- and demuxed-audio sources in one channel
+
+Scoping note for issue #381 (parent #271; implementation sub-issues #382/#383).
+This document defines the target behaviour and acceptance criteria before any
+implementation is started. It contains no code.
+
+## Problem
+
+A channel is fed a sequence of VOD (and optionally live) sources by the asset
+manager. Today those sources are assumed to be homogeneous with respect to
+audio packaging: either every source is *muxed* (audio interleaved in the same
+rendition as video) or every source is *demuxed* (audio delivered as a separate
+`EXT-X-MEDIA` audio group). The channel-level `useDemuxedAudio` flag
+(`engine/server.ts`) picks one mode for the whole channel and every source is
+expected to comply with it.
+
+When a channel's schedule mixes the two — e.g. a muxed VOD followed by a
+demuxed VOD on a `useDemuxedAudio: true` channel — the mismatched source fails
+to load rather than being reconciled. This is grounded in the current code (see
+"Affected code paths" below): `engine/session.ts` passes
+`forcedDemuxMode: this.use_demuxed_audio` into the underlying `HLSVod`
+(`@eyevinn/hls-vodtolive`), and that library **rejects with
+`Error("The vod is not a demux vod")`** when a source presented under forced
+demux mode carries no audio group. So a muxed source on a demuxed channel is a
+hard load failure today, not a soft mismatch.
+
+## (1) Target behaviour
+
+For a single channel whose sources mix muxed-audio and demuxed-audio inputs:
+
+- The sources must play **back-to-back across the VOD boundary without breaking
+  the manifest** — the output master playlist and the output media/audio
+  playlists must remain valid and internally consistent across the transition,
+  and a compliant player must continue playback across the boundary without a
+  fatal error or a manifest reload failure.
+- A brief, bounded audio artefact at the discontinuity (one segment of silence
+  or a single hiccup, on the order of the average segment duration) is
+  acceptable for a first pass; a persistent audio/video desync or a manifest
+  that a player rejects is **not** acceptable.
+- "Mix" here covers the VOD→VOD case as the primary target. Live-mix
+  (VOD↔live) transitions with mixed packaging are in scope for the acceptance
+  criteria only insofar as they must not regress the existing live-mix +
+  demux behaviour; full live-mix mixed-packaging support may be deferred to a
+  follow-up if it proves materially harder.
+
+## (2) Output manifest mode — recommendation
+
+**Normalise to a single, consistent output presentation for the whole channel.**
+Do not preserve per-source packaging in the output. A channel that flips the
+output between muxed and demuxed at each VOD boundary would force the player to
+re-init its audio pipeline mid-stream and is the most likely thing to break
+playback.
+
+Concretely: the channel's output mode is decided once, by the existing
+`useDemuxedAudio` flag.
+
+- `useDemuxedAudio: true`  → output is **always demuxed**: an `EXT-X-MEDIA`
+  audio group is present and every served segment (from every source,
+  regardless of that source's own packaging) participates in that single
+  consistent audio-group presentation.
+- `useDemuxedAudio: false` → output is **always muxed**: no separate audio
+  group; audio is carried in the video rendition for every source.
+
+The flag stays the single source of truth for output presentation; the new work
+is making non-conforming sources fit the chosen output mode rather than failing.
+
+## (3) Cross-packaging handling (muxed source, demuxed output — and vice-versa)
+
+**On-the-fly remultiplexing / transcoding is explicitly out of scope.** The
+engine is a manifest-manipulation / VOD2Live layer; it does not open, decode,
+demux, or re-encode media segments, and it should not start doing so here.
+
+Given that constraint, the two cross-packaging directions resolve as:
+
+- **Muxed source, demuxed output (`useDemuxedAudio: true`)**: require the muxed
+  source to **already carry a separate audio rendition** (an `EXT-X-MEDIA`
+  audio group) that the engine can route into the output audio group. A source
+  that is *only* muxed (video-with-embedded-audio and no audio rendition)
+  cannot be losslessly presented as demuxed without extracting the audio track,
+  which is remux — out of scope. Such a source must be handled deterministically
+  (see acceptance criteria: reject-and-skip via the existing error/unassign
+  path, not a crash), not silently mis-served.
+- **Demuxed source, muxed output (`useDemuxedAudio: false`)**: the engine
+  selects a single audio rendition from the source's audio group and presents
+  the source as muxed in the output. Where the source's video rendition does
+  not already contain that audio, this again requires the player to be served
+  audio it can associate with the video without a remux; if that cannot be done
+  losslessly it falls under the same deterministic reject-and-skip rule.
+
+In short: **the engine reconciles packaging by routing existing renditions, not
+by producing new media.** A source that would require new media to fit the
+output mode is rejected cleanly rather than breaking the channel.
+
+## (4) Affected code paths
+
+Verified against the current tree (the engine files are TypeScript, `*.ts`, not
+`*.js` as the parent issue's shorthand suggested):
+
+- **`engine/server.ts`** — declares and stores the `useDemuxedAudio` option
+  (`ChannelEngineOpts.useDemuxedAudio`, the private `useDemuxedAudio` field,
+  and its default-to-`false` handling), and forwards it into the session /
+  session-live / stream-switcher configs it constructs. This is where the
+  "output mode is a single channel-level decision" contract lives.
+- **`engine/session.ts`** — reads the flag into `use_demuxed_audio` and, at VOD
+  creation, passes `forcedDemuxMode: this.use_demuxed_audio` into `new
+  HLSVod(...)`. This is the exact point where a muxed source on a demuxed
+  channel currently causes the underlying library to reject with "The vod is
+  not a demux vod". The reconciliation/validation decided above must be applied
+  here (and it must feed the existing per-item error handling rather than
+  throwing uncaught).
+- **`engine/session_live.ts`** — mirrors the demuxed handling for the live
+  path (`this.useDemuxedAudio`, the audio-disc-sequence and audio-segment
+  branches). Any normalisation must keep the live path's audio group consistent
+  with the VOD path across a live-mix transition.
+- **`engine/stream_switcher.ts`** — gates transitions on the presence of audio
+  segments when `useDemuxedAudio` is set (the `isValid` /
+  `ItemIsEmpty(segments.audioSegments)` checks and the numerous
+  `this.useDemuxedAudio` branches around the switch logic). This is where a
+  packaging mismatch at a boundary is currently detected as "no audio
+  segments"; the reject-and-skip vs. reconcile decision must be enforced
+  consistently here too, so the switcher never advances into a state that
+  produces an invalid manifest.
+
+## Acceptance criteria
+
+The implementation sub-issues (#382/#383) can be validated against this list:
+
+- [ ] The channel's output presentation is decided solely by `useDemuxedAudio`
+      and is identical for every source in the channel (never flips
+      muxed/demuxed mid-stream).
+- [ ] A schedule that alternates a demuxed source and a *muxed source that
+      already carries an audio rendition* on a `useDemuxedAudio: true` channel
+      plays across the VOD boundary and produces a valid master + media + audio
+      playlist at and after the transition.
+- [ ] The same alternation on a `useDemuxedAudio: false` channel produces valid
+      muxed output across the boundary.
+- [ ] A muxed-only source (no audio rendition) presented to a
+      `useDemuxedAudio: true` channel is handled deterministically: it is
+      rejected/skipped through the existing error → unassign → next-item path
+      (per the repo's "on any unexpected failure" rule) and does **not** crash
+      the session, wedge the stream switcher, or emit an invalid manifest.
+- [ ] No segment-level remux/transcode is introduced anywhere in
+      `engine/session.ts`, `engine/session_live.ts`, or
+      `engine/stream_switcher.ts` (reconciliation is rendition routing only).
+- [ ] Existing homogeneous-packaging behaviour (all-muxed channel, all-demuxed
+      channel) is unchanged — the current session / session_live /
+      stream_switcher specs still pass.
+- [ ] A regression spec drives a mixed-packaging schedule through the same
+      seam the engine uses (VOD load → live media sequence render, as in the
+      existing `spec/engine/session_spec.ts`) and asserts a valid transition
+      rather than the current `"The vod is not a demux vod"` rejection.
+- [ ] The README "Supported Source Formats" section is updated to describe
+      mixed-packaging support once implemented.

package/docs/design/subtitles-live-mix-demux.md

@@ -0,0 +1,135 @@
+# Design note: subtitles in the live-mix + demux setting
+
+Scoping note for issue #402. This document defines what "subtitle support in the
+live-mix + demux setting" should mean and the acceptance criteria a follow-up
+implementation issue can be filed against. It contains no code.
+
+## Problem
+
+`README.md`, directly under the "Supported Source Formats" compliance table,
+states:
+
+> NOTE: The engine does not support subtitles in the live-mix + demux setting.
+
+The table backs this up: the `Mix w. Live & Subtitles` column is `No` for both
+the `HLS + TS` and `HLS + CMAF` rows.
+
+This is grounded in the current code:
+
+- The VOD-only path (`engine/session.ts`) **does** implement subtitles — it has
+  a working `getCurrentSubtitleManifestAsync(...)` and the
+  `useVTTSubtitles` / `dummySubtitleEndpoint` / `subtitleSliceEndpoint`
+  configuration wiring.
+- The live path (`engine/session_live.ts`) does **not**: its
+  `getCurrentSubtitleManifestAsync(...)` is a stub that logs
+  `"getCurrentSubtitleManifestAsync is NOT Implemented"` and returns nothing.
+  A code comment in that file explicitly notes subtitle support for live-mix is
+  future work.
+- `engine/stream_switcher.ts` has no subtitle handling at all; it reconciles
+  video and (when demuxed) audio across a transition, but nothing for a
+  subtitle rendition.
+
+So today, once a channel enters the live-mix path, any subtitle rendition the
+VOD side was serving has no live-side counterpart and no switcher continuity —
+the gap the README documents.
+
+## (a) What "supported" means — the explicit target
+
+Two candidate definitions:
+
+1. **Continuity**: the subtitle track keeps playing across the mix transition —
+   the output subtitle rendition stays present and valid through the VOD→live
+   (and live→VOD) boundary so a player selecting subtitles never loses them.
+2. **No-crash-only**: subtitles may drop during the live portion, but audio and
+   video must not break and the manifest must stay valid.
+
+**Chosen target: (1) continuity.**
+
+Justification: the compliance table's `Subtitles` column is already `Yes` for
+the non-live cases, so users who reach live-mix reasonably expect subtitles to
+keep working, not to silently disappear. A player that is told (via
+`EXT-X-MEDIA TYPE=SUBTITLES`) that a subtitle group exists and then finds it
+empty/absent during the live window is a worse, more confusing experience than
+a clean drop — and "no-crash-only" is largely already true in practice (the
+current failure mode is a missing/blank subtitle manifest, not a video crash),
+so it would be a near-no-op target. Committing to continuity is the change that
+actually closes the documented gap.
+
+Continuity is defined concretely as: across the mix boundary the output master
+playlist continues to advertise the same `EXT-X-MEDIA TYPE=SUBTITLES` group,
+and the subtitle media playlist for that group continues to return valid,
+monotonically advancing segments (real cues where the source has them, and
+timed empty/dummy WebVTT segments where the live source has no cues) with no
+gap that a compliant player rejects.
+
+## (b) Which compliance-table cells this closes, and format scope
+
+The two currently-`No` cells are `Mix w. Live & Subtitles` for `HLS + TS` and
+for `HLS + CMAF`.
+
+**First-pass scope: `HLS + CMAF` only.** Recommendation is to close the
+`HLS + CMAF` cell first and leave `HLS + TS` for a follow-up.
+
+Rationale: the demux + subtitle plumbing on the VOD side (and the existing
+livemix-demux support noted in the README) is exercised most with CMAF/fMP4
+content, and segment-aligned CMAF makes the timed-empty-segment continuity
+approach simpler to reason about at the boundary. `HLS + TS` can follow once the
+CMAF path is proven, reusing the same switcher continuity logic. The
+acceptance criteria below are written so the `HLS + TS` cell can be closed later
+by re-running the same fixture shape against TS content without a redesign.
+
+So: this note's implementation issue closes the **`HLS + CMAF`** `Mix w. Live &
+Subtitles` cell; the `HLS + TS` cell is explicitly deferred.
+
+## (c) Concrete test fixture
+
+A live-mix session with an active subtitle track transitioning across a VOD
+boundary:
+
+- A `useDemuxedAudio: true`, `useVTTSubtitles: true` channel.
+- Schedule: a **VOD source that carries a WebVTT subtitle rendition** →
+  transition into a **live source** (the live-mix path) → transition back to a
+  VOD source with subtitles.
+- The live source is the `Mix w. Live` case, so it drives the
+  `engine/session_live.ts` + `engine/stream_switcher.ts` paths rather than the
+  VOD-only `engine/session.ts` path.
+- Assertion seam: render the subtitle media playlist (the output of the
+  subtitle-manifest path) at media sequences spanning the VOD→live→VOD
+  boundaries and assert the subtitle group remains advertised in the master and
+  the subtitle playlist stays valid and continuous across each boundary — using
+  the same offline render-and-assert approach as the existing
+  `spec/engine/subtitle_spec.ts` / `spec/engine/session_spec.ts`, so it runs in
+  CI without a live encoder.
+
+The fixture should reuse existing subtitle test vectors where possible (e.g. the
+`hls_subs*` / `hls_subs7_demux` vectors in `@eyevinn/hls-vodtolive/testvectors`)
+plus the existing local `spec/testvectors/subtitle_file*.webvtt` files, paired
+with a live playlist fixture for the mix segment.
+
+## Acceptance criteria
+
+A follow-up `feat:` implementation issue can be validated against:
+
+- [ ] "Supported" is resolved to a single explicit target — **subtitle
+      continuity across the mix transition** (not merely no-crash) — as defined
+      in section (a).
+- [ ] Format scope is stated: **`HLS + CMAF` in the first pass; `HLS + TS`
+      deferred to a follow-up.**
+- [ ] A named test fixture exists: a live-mix session (`useDemuxedAudio: true`,
+      `useVTTSubtitles: true`) with an active WebVTT subtitle track
+      transitioning across a VOD→live→VOD boundary, asserted offline in CI.
+- [ ] `engine/session_live.ts` `getCurrentSubtitleManifestAsync(...)` returns a
+      valid subtitle manifest for the live window instead of the current
+      "NOT Implemented" stub.
+- [ ] `engine/stream_switcher.ts` reconciles the subtitle rendition across a
+      transition the same way it already reconciles the demuxed audio
+      rendition, so the subtitle group is never dropped from the output master
+      mid-channel.
+- [ ] Across the boundary the output subtitle playlist advances monotonically
+      with no gap a compliant player rejects (real cues where present, timed
+      empty WebVTT segments where the live source has none).
+- [ ] The README compliance table's `Mix w. Live & Subtitles` cell for
+      `HLS + CMAF` is changed from `No` to `Yes`, and the note under the table
+      is updated to reflect the remaining `HLS + TS` gap.
+- [ ] Existing subtitle and live-mix specs still pass (no regression to the
+      VOD-only subtitle path or to livemix-demux without subtitles).

package/docs/reference.md

@@ -28,3 +28,70 @@ uri | HLSURI | string | URI to HLS master manifest for the VOD
 title (optional) | TITLE | string |  The title of the asset
 playlistPosition (optional) | POSITION | id | Current position of the VOD in the playlist
 
+## Ad-break configuration (HLS interstitials)
+
+The engine can annotate a channel's manifest with SGAI HLS-interstitial
+[EXT-X-DATERANGE](https://datatracker.ietf.org/doc/html/rfc8216) tags
+(`CLASS="com.apple.hls.interstitial"`) so that an HLS player performs
+client-side ad replacement at the VOD boundary. Ad breaks are configured
+through the `adBreak` object, which can be set either as an engine-level
+default (on `ChannelEngineOpts`) or per channel (on a `Channel`). A
+per-channel `adBreak` overrides the engine-level default. Ad breaks default
+to **disabled** when neither is set.
+
+### `adBreak` fields
+
+Field | Type | Default | Description
+----- | ---- | ------- | -----------
+enabled | boolean | `false` | Master enable flag. When `false`, no interstitial metadata is emitted and the served manifest is byte-identical to the non-ad-break output.
+adServerUri | string | (none) | URL of the ad-serving endpoint queried to fill a break. **Required** when `enabled` is `true`, and validated to be an absolute `http`/`https` URL — an enabled break with a missing or invalid `adServerUri` throws at engine construction.
+slate (optional) | object | (none) | Slate reference shown while the break is being resolved and used as the fallback asset if the ad-serving endpoint cannot be resolved. Omit to fall back to the channel/engine slate configuration.
+
+### `adBreak.slate` fields
+
+Field | Type | Default | Description
+----- | ---- | ------- | -----------
+uri | string | (none) | URI to the slate HLS VOD.
+repetitions (optional) | number | `10` | Number of times the slate VOD is repeated to fill the break window.
+duration (optional) | number | `4000` | Duration of a single slate repetition, in milliseconds. Together with `repetitions` this drives the interstitial `PLANNED-DURATION`.
+
+### Ad replacement flow
+
+When a break is opened on an enabled channel:
+
+1. The engine queries the configured `adServerUri` for an ad asset (with an
+   `Accept: application/json` request and a 2-second timeout).
+2. The endpoint answers with a JSON body in one of these shapes:
+
+   Response body | Interstitial attribute
+   ------------- | ----------------------
+   `{ "assetUri": "<uri>" }` | `X-ASSET-URI` (single asset)
+   `{ "assetList": "<uri>" }` | `X-ASSET-LIST` (an asset-list endpoint)
+   `{ "assets": ["<uri>", ...] }` | `X-ASSET-URI` from the first entry
+
+3. The resolved asset is written into an EXT-X-DATERANGE HLS interstitial on
+   the served manifest, and the HLS player fetches and plays the ad in place
+   of (client-side ad replacement), leaving the underlying VOD2Live stream
+   untouched.
+4. If the endpoint times out, returns a non-2xx status, or returns a
+   malformed/empty body, the engine logs and falls back to the configured
+   slate (or the channel/engine slate) so the break still renders — the
+   session tick is never interrupted.
+
+See `examples/adbreak.ts` for a runnable channel wired with an ad break.
+
+## Custom VOD request parameters
+
+The engine can be configured with an allowlist of query-parameter names that are
+permitted to be forwarded to the asset manager's `getNextVod()` request. This is
+set through the `customVodRequestParams` option on `ChannelEngineOpts`. Only
+parameters whose name appears in the allowlist may be passed through; every other
+query parameter is ignored. When the option is omitted the allowlist is empty, so
+no parameters are forwarded (the default, current behaviour).
+
+### `ChannelEngineOpts` fields
+
+Field | Type | Default | Description
+----- | ---- | ------- | -----------
+customVodRequestParams (optional) | string[] | `[]` (empty — no pass-through) | Allowlist of query-parameter names permitted to be forwarded to `getNextVod()`. Config surface only for now; the forwarding itself is wired up in follow-up work.
+

package/engine/chaos_monkey.ts

@@ -0,0 +1,17 @@
+const debug = require('debug')('chaos-monkey');
+
+const CHAOS_MONKEY_PROBABILITY: string | number = process.env.CHAOS_MONKEY_PROBABILITY || 0.5;
+const doChaos = (): boolean => process.env.CHAOS_MONKEY === "true" && Math.random() < (CHAOS_MONKEY_PROBABILITY as number);
+
+const loadVod = async <T>(p: Promise<T>): Promise<T> => {
+  if (doChaos()) {
+    debug("Chaos Monkey is doing stuff");
+    throw new Error("Chaos monkey prevented you from loading a VOD");
+  } else {
+    return await p;
+  }
+};
+
+module.exports = {
+  loadVod
+};

package/engine/{event_stream.js → event_stream.ts}

@@ -1,11 +1,13 @@
 class EventStream {
-  constructor(session) {
+  private _session: any;
+
+  constructor(session: any) {
     this._session = session;
   }
 
-  poll() {
+  poll(): Promise<string> {
     return new Promise((resolve, reject) => {
-      let event = {};
+      let event: any = {};
       event = this._session.consumeEvent();
       if (event) {
         resolve(JSON.stringify(event));

package/engine/{memcached_state_store.js → memcached_state_store.ts}

@@ -1,8 +1,15 @@
 const MemcacheClient = require("memcache-client");
 const debug = require("debug")("memcached-state-store");
 
-class MemcachedStateStore {
-  constructor(keyPrefix, opts) {
+import type { IStateStore } from "./state_store_types";
+
+// Type-only migration (#373): a faithful port of the original JS.
+
+class MemcachedStateStore implements IStateStore {
+  keyPrefix: string;
+  client: any;
+
+  constructor(keyPrefix: string, opts: any) {
     this.keyPrefix = keyPrefix;
     if (opts.version) {
       const prependPrefix = opts.version.replace(/\./g, "X");
@@ -12,9 +19,9 @@ class MemcachedStateStore {
     this.client = new MemcacheClient({ server: opts.memcachedUrl, cmdTimeout: 10000 });
   }
 
-  async initAsync(id, initData) {
+  async initAsync(id: string, initData: Record<string, any>): Promise<Record<string, any>> {
     const isInitiated = await this.getAsync(id, "_initiated");
-    let data = {};
+    let data: Record<string, any> = {};
     if (!isInitiated) {
       for(const key of Object.keys(initData)) {
         debug(`${this.keyPrefix}:${id}: Initiating key ${key} with init data`);
@@ -31,16 +38,16 @@ class MemcachedStateStore {
     return data;
   }
 
-  async resetAsync(id, initData) {
+  async resetAsync(id: string, initData: Record<string, any>): Promise<void> {
     await this.setAsync(id, "_initiated", false);
     await this.initAsync(id, initData);
   }
 
-  async resetAllAsync() {
+  async resetAllAsync(): Promise<void> {
     console.error("Shared Storage Reset Failed.\nMemcache-client: Flush All Command Not Implemented Yet");
   }
 
-  async getAsync(id, key) {
+  async getAsync(id: string, key: string): Promise<any> {
     const storeKey = "" + this.keyPrefix + id + key;
     const data = await this.client.get(storeKey);
     if (data) {
@@ -49,19 +56,19 @@ class MemcachedStateStore {
     return null;
   }
 
-  async setAsync(id, key, value) {
+  async setAsync(id: string, key: string, value: any): Promise<any> {
     const storeKey = "" + this.keyPrefix + id + key;
     await this.client.set(storeKey, JSON.stringify(value));
     return value;
   }
 
-  async setVolatileAsync(id, key, value) {
+  async setVolatileAsync(id: string, key: string, value: any): Promise<any> {
     throw new Error("memcached: setVolatileAsync not implemented yet");
   }
 
-  async removeAsync(id, key) {
+  async removeAsync(id: string, key: string): Promise<any> {
     throw new Error("memcached: removeAsync not implemented yet");
-  }  
+  }
 }
 
-module.exports = MemcachedStateStore;
+module.exports = MemcachedStateStore;

package/engine/memory_state_store.ts

@@ -0,0 +1,71 @@
+const debug = require("debug")("memory-state-store");
+
+import type { IStateStore, SharedStates } from "./state_store_types";
+
+// Type-only migration (#373): a faithful port of the original JS. Runtime
+// behavior and the exported constructor signature are unchanged.
+
+class MemoryStateStore implements IStateStore {
+  sharedStates: SharedStates;
+  globalSharedStates: { [key: string]: any };
+
+  constructor(type?: string, opts?: any) {
+    this.sharedStates = {};
+    this.globalSharedStates = {};
+  }
+
+  async initAsync(id: string, initData: Record<string, any>): Promise<any> {
+    if (!this.sharedStates[id]) {
+      this.sharedStates[id] = {};
+      Object.keys(initData).forEach((key) => {
+        (this.sharedStates[id] as { [key: string]: any })[key] = initData[key];
+      });
+    }
+    return this.sharedStates[id];
+  }
+
+  async resetAsync(id: string, initData: Record<string, any>): Promise<void> {
+    this.sharedStates[id] = null;
+    await this.initAsync(id, initData);
+  }
+
+  async resetAllAsync(): Promise<void> {
+      this.sharedStates = {};
+      this.globalSharedStates = {};
+  }
+
+  async getAsync(id: string, key: string): Promise<any> {
+    let value;
+    if (id === "" || id === null) {
+      value = this.globalSharedStates[key];
+    } else {
+      if (!this.sharedStates[id]) {
+        return null;
+      }
+      value = (this.sharedStates[id] as { [key: string]: any })[key];
+    }
+    return value;
+  }
+
+  async setAsync(id: string, key: string, value: any): Promise<any> {
+    if (id === "" || id === null) {
+      this.globalSharedStates[key] = value;
+    } else {
+      if (!this.sharedStates[id]) {
+        this.sharedStates[id] = {};
+      }
+      (this.sharedStates[id] as { [key: string]: any })[key] = value;
+      return (this.sharedStates[id] as { [key: string]: any })[key];
+    }
+  }
+
+  async setVolatileAsync(id: string, key: string, value: any): Promise<any> {
+    return await this.setAsync(id, key, value);
+  }
+
+  async removeAsync(id: string, key: string): Promise<void> {
+    delete (this.sharedStates[id] as { [key: string]: any })[key];
+  }
+}
+
+module.exports = MemoryStateStore;