@oneuptime/common 12.0.8 → 12.0.9

package/Types/OnCallDutyPolicy/Layer.ts

@@ -1517,181 +1517,237 @@ export default class LayerUtil {
     events: PriorityCalendarEvents[],
   ): CalendarEvent[] {
     /*
-     * now remove overlapping events by priority and trim them by priority. Lower priority number will be kept and higher priority number will be trimmed.
-     * so if there are two events with the same start and end time, we will keep the one with the lower priority number and remove the one with the higher priority number.
-     * if there are overlapping events, we will trim the one with the higher priority number.
+     * Flatten overlapping events by priority. A LOWER priority number wins: an
+     * event is trimmed back so it does not overlap any higher-priority (lower
+     * numbered) event, and where a lower-priority event straddles a
+     * higher-priority one it is split into a leading and a trailing segment.
+     * Segments are separated by a 1-second seam.
+     *
+     * This runs on the browser's main thread on the on-call schedule screen,
+     * over every event in the coverage window — an hourly rotation over three
+     * months is thousands of events. The previous implementation had three
+     * separate problems here, in increasing order of severity:
+     *
+     *   - CONSTANT FACTOR. Every comparison went through `OneUptimeDate.*`,
+     *     which wraps each operand in a moment object (via `fromString`) —
+     *     roughly 8 allocations per overlap test, and it dominated the profile.
+     *     All comparisons below are numeric `getTime()` instead. Timestamps are
+     *     normalised once, up front, so string-typed inputs are still accepted.
+     *   - COMPLEXITY. The inner scan walked the whole of `finalEvents` for every
+     *     event placed, which is O(n^2): ~1000 hourly events took over a minute,
+     *     and every re-render of the schedule screen paid it again.
+     *     `activeEventIndexes` keeps the scan off events that can no longer
+     *     match. Events are processed in ascending start order and an event's
+     *     start only ever moves forward, so once a placed event ends at or
+     *     before the current start it cannot overlap this event or any later
+     *     one, and is dropped from the scan for good.
+     *   - TERMINATION. On some inputs it never finished at all — see the
+     *     exhausted-event break inside the scan below. That was the real bug;
+     *     the two above only made the schedule screen slow.
      */
 
-    // sort the events by priority
-
-    // now remove the overlapping events
-
-    // remove events where start time and end time are the same
+    /*
+     * Normalise to real Dates once. Everything below reads `.getTime()`
+     * directly, which is only safe if these are Date instances — callers may
+     * hand us JSON-deserialised events whose start/end are strings, which the
+     * old `OneUptimeDate.*` comparisons coerced on every single call.
+     */
+    for (const event of events) {
+      event.start = OneUptimeDate.fromString(event.start);
+      event.end = OneUptimeDate.fromString(event.end);
+    }
 
+    // Drop zero-length and inverted events; the merge below assumes end > start.
     events = events.filter((event: PriorityCalendarEvents) => {
-      return !OneUptimeDate.isSame(event.start, event.end);
+      return event.end.getTime() > event.start.getTime();
     });
 
-    // remove events where start time is after end time
-    events = events.filter((event: PriorityCalendarEvents) => {
-      return !OneUptimeDate.isBefore(event.end, event.start);
+    /*
+     * Ascending start time. Array.prototype.sort is stable, so events that share
+     * a start stay in insertion order — which is layer order, i.e. ascending
+     * priority. The merge below depends on this ordering in both directions:
+     * ascending starts let the active-set pruning work, and the priority tie
+     * order decides which of two same-start events is the one that gets trimmed.
+     */
+    events.sort((a: CalendarEvent, b: CalendarEvent) => {
+      return a.start.getTime() - b.start.getTime();
     });
 
     const finalEvents: PriorityCalendarEvents[] = [];
 
-    // sort events by start time
-
-    events.sort((a: CalendarEvent, b: CalendarEvent) => {
-      if (OneUptimeDate.isBefore(a.start, b.start)) {
-        return -1;
-      }
-
-      if (OneUptimeDate.isAfter(a.start, b.start)) {
-        return 1;
-      }
+    /*
+     * Indexes into finalEvents that may still overlap the event being placed,
+     * in ascending index order — the same order the old full scan visited them
+     * in. Order is load-bearing, not incidental: trimming a lower-priority final
+     * event uses the current event's start, which a higher-priority final event
+     * visited earlier in the same scan may already have pushed forward.
+     */
+    const activeEventIndexes: number[] = [];
 
-      return 0;
-    });
+    // Tombstones. Splicing finalEvents mid-merge would invalidate these indexes.
+    const removedEventIndexes: Set<number> = new Set<number>();
 
     for (const event of events) {
-      // trim the trimmed events by the current event based on priority
+      const eventEndTime: number = event.end.getTime();
 
-      // if this event starts and end at the same time, we need to remove it
-      if (OneUptimeDate.isSame(event.start, event.end)) {
-        continue;
-      }
-
-      // if the end time of the event is before the start time, we need to remove it
-      if (OneUptimeDate.isBefore(event.end, event.start)) {
-        continue;
-      }
+      /*
+       * Retire everything that ends at or before this event's start. Events
+       * arrive in ascending start order, so nothing retired here can overlap any
+       * later event either. Each index is examined once more after it stops
+       * matching, making this O(1) amortised per placed event.
+       */
+      const eventStartTime: number = event.start.getTime();
+      let keptCount: number = 0;
 
-      for (let i: number = 0; i < finalEvents.length; i++) {
-        const finalEvent: PriorityCalendarEvents | undefined = finalEvents[i];
+      for (let i: number = 0; i < activeEventIndexes.length; i++) {
+        const index: number = activeEventIndexes[i]!;
 
-        if (!finalEvent) {
+        if (removedEventIndexes.has(index)) {
           continue;
         }
 
-        // check if this final event overlaps with the current event
-        if (
-          OneUptimeDate.isOverlapping(
-            finalEvent.start,
-            finalEvent.end,
-            event.start,
-            event.end,
-          )
-        ) {
-          // if the current event has a higher priority than the final event, we need to trim the final event
-          if (event.priority < finalEvent.priority) {
-            /*
-             * trim the final event based on the current event
-             * end time of the final event will be the start time of the current event - 1 second
-             */
-            const tempFinalEventEnd: Date = finalEvent.end;
-
-            /*
-             * Reconstruct the trailing tail FIRST, before the front-collapse
-             * removal below. If the lower-priority (fallback) event originally
-             * extended past the higher-priority event, the portion AFTER the
-             * higher-priority window must survive as its own segment — even when
-             * the FRONT of the final event collapses to zero/negative length
-             * (which happens when the higher-priority event starts at or before
-             * the final event's start, e.g. two back-to-back higher-priority
-             * rotation windows over a 24/7 fallback layer). Previously this block
-             * ran only AFTER the collapse checks, whose `continue` skipped it,
-             * silently deleting the fallback layer's coverage after the higher-
-             * priority window and leaving on-call gaps where nobody is paged.
-             */
-            if (OneUptimeDate.isAfter(tempFinalEventEnd, event.end)) {
-              // add the trailing segment of the lower-priority event
-              const trimmedEvent: PriorityCalendarEvents = {
-                ...finalEvent,
-                priority: finalEvent.priority,
-                start: OneUptimeDate.addRemoveSeconds(event.end, 1),
-                end: tempFinalEventEnd,
-              };
-
-              // only keep it if it has positive length
-              if (OneUptimeDate.isAfter(trimmedEvent.end, trimmedEvent.start)) {
-                finalEvents.push(trimmedEvent);
-              }
-            }
-
-            finalEvent.end = OneUptimeDate.addRemoveSeconds(event.start, -1);
-
-            /*
-             * check if the final event end time is before the start time of the current event
-             * if it is, we need to remove the final event from the final events array
-             * (the trailing tail, if any, was already preserved above)
-             */
-            if (OneUptimeDate.isBefore(finalEvent.end, finalEvent.start)) {
-              finalEvents.splice(i, 1);
-              i--; // Adjust index after removal
-              continue;
-            }
-
-            // if end and start time of the final event is same, we need to remove it
-            if (OneUptimeDate.isSame(finalEvent.start, finalEvent.end)) {
-              finalEvents.splice(i, 1);
-              i--; // Adjust index after removal
-              continue;
-            }
-          } else {
-            /*
-             * Trim the current (lower-priority) event: push its start past this
-             * higher-priority window. Use getGreaterDate (a monotonic max)
-             * instead of a bare assignment so the result does NOT depend on the
-             * order finalEvents are visited. That makes it safe to hoist the
-             * per-iteration finalEvents.sort() out of the loop (audit H2): with
-             * the old in-loop ascending sort, successive overlaps already had
-             * monotonically increasing ends, so max equals the old assignment and
-             * the output is unchanged.
-             */
-            event.start = OneUptimeDate.getGreaterDate(
-              event.start,
-              OneUptimeDate.addRemoveSeconds(finalEvent.end, 1),
-            );
-          }
+        if (finalEvents[index]!.end.getTime() <= eventStartTime) {
+          continue;
         }
-      }
 
-      // check if the event end time is before the start time of the current event
-      if (OneUptimeDate.isAfter(event.end, event.start)) {
-        finalEvents.push(event);
+        activeEventIndexes[keptCount] = index;
+        keptCount++;
       }
 
+      activeEventIndexes.length = keptCount;
+
       /*
-       * The finalEvents.sort() that used to run HERE — inside the per-event
-       * loop — made the merge O(n^2 log n). It is hoisted to a single sort after
-       * the loop (below). Correctness is preserved because overlap detection and
-       * trimming do not depend on finalEvents being sorted (the current-event
-       * trim above now uses a monotonic max), so sorting once at the end yields
-       * the same result. Audit H2.
+       * Length is re-read each pass: trailing segments appended below join the
+       * scan, exactly as they did when this walked finalEvents directly. They
+       * start after this event ends, so they never match it — but the scan is
+       * kept faithful rather than relying on that.
        */
+      for (let i: number = 0; i < activeEventIndexes.length; i++) {
+        const currentStart: number = event.start.getTime();
 
-      // if an event starts and end at the same time, we need to remove it
+        /*
+         * Nothing left of this event. The else-branch below pushes its start
+         * forward past each higher-priority window it meets, and that can
+         * consume the event entirely — at which point it covers no time, will
+         * not be placed, and must stop trimming other events.
+         *
+         * WITHOUT this stop the merge does not terminate, which is the bug this
+         * whole rewrite exists to fix. `OneUptimeDate.isOverlapping` reports a
+         * zero-length or inverted interval as overlapping anything that shares
+         * an endpoint with it (its moment `isBetween` bounds are exclusive, but
+         * it also has explicit start===start / end===end arms). So an exhausted
+         * event kept matching the very tail segment it had just created, split
+         * it again, matched the new tail, and so on forever. Empirically an
+         * hourly grid with 3 priorities settled at 14 events and never returned
+         * at 16.
+         *
+         * Stopping here is also the correct answer rather than merely a
+         * terminating one: an event with no remaining duration represents nobody
+         * on call, so letting it carve a second out of a lower-priority event
+         * opened a 1-second hole in the fallback coverage for no reason.
+         */
+        if (currentStart >= eventEndTime) {
+          break;
+        }
 
-      for (let index: number = 0; index < finalEvents.length; index++) {
-        const finalEvent: PriorityCalendarEvents | undefined =
-          finalEvents[index];
+        const finalEventIndex: number = activeEventIndexes[i]!;
 
-        if (!finalEvent) {
+        if (removedEventIndexes.has(finalEventIndex)) {
           continue;
         }
 
-        if (OneUptimeDate.isSame(finalEvent.start, finalEvent.end)) {
-          finalEvents.splice(index, 1);
-          index--; // Adjust index after removal
+        const finalEvent: PriorityCalendarEvents =
+          finalEvents[finalEventIndex]!;
+
+        const finalStart: number = finalEvent.start.getTime();
+        const finalEnd: number = finalEvent.end.getTime();
+
+        /*
+         * Half-open overlap: touching endpoints do not overlap. Both intervals
+         * are guaranteed positive-length here — final events are length-checked
+         * before being placed, and the current event is checked by the break
+         * above — and over positive-length intervals this is exactly equivalent
+         * to the OneUptimeDate.isOverlapping it replaces.
+         */
+        if (currentStart >= finalEnd || finalStart >= eventEndTime) {
           continue;
         }
 
-        // if any event ends before it starts, we need to remove it
-        if (OneUptimeDate.isBefore(finalEvent.end, finalEvent.start)) {
-          finalEvents.splice(index, 1);
-          index--; // Adjust index after removal
+        if (event.priority < finalEvent.priority) {
+          /*
+           * The current event outranks this one. Trim the final event back to
+           * end 1s before the current event starts.
+           */
+          const tempFinalEventEnd: Date = finalEvent.end;
+
+          /*
+           * Reconstruct the trailing tail FIRST, before the front-collapse
+           * removal below. If the lower-priority (fallback) event originally
+           * extended past the higher-priority event, the portion AFTER the
+           * higher-priority window must survive as its own segment — even when
+           * the FRONT of the final event collapses to zero/negative length
+           * (which happens when the higher-priority event starts at or before
+           * the final event's start, e.g. two back-to-back higher-priority
+           * rotation windows over a 24/7 fallback layer). Previously this block
+           * ran only AFTER the collapse checks, whose `continue` skipped it,
+           * silently deleting the fallback layer's coverage after the higher-
+           * priority window and leaving on-call gaps where nobody is paged.
+           */
+          if (tempFinalEventEnd.getTime() > eventEndTime) {
+            // add the trailing segment of the lower-priority event
+            const trimmedEvent: PriorityCalendarEvents = {
+              ...finalEvent,
+              priority: finalEvent.priority,
+              start: new Date(eventEndTime + 1000),
+              end: tempFinalEventEnd,
+            };
+
+            // only keep it if it has positive length
+            if (trimmedEvent.end.getTime() > trimmedEvent.start.getTime()) {
+              activeEventIndexes.push(finalEvents.length);
+              finalEvents.push(trimmedEvent);
+            }
+          }
+
+          finalEvent.end = new Date(currentStart - 1000);
+
+          /*
+           * If the front collapsed to zero or negative length, drop it. The
+           * trailing tail, if any, was already preserved above.
+           */
+          if (finalEvent.end.getTime() <= finalStart) {
+            removedEventIndexes.add(finalEventIndex);
+          }
+        } else {
+          /*
+           * Trim the current (lower-priority) event: push its start past this
+           * higher-priority window. This is a monotonic max rather than a bare
+           * assignment so the result does NOT depend on the order finalEvents
+           * are visited. That is what made it safe to hoist the per-iteration
+           * finalEvents.sort() out of the loop (audit H2).
+           */
+          const trimmedStart: number = finalEnd + 1000;
+
+          if (trimmedStart > currentStart) {
+            event.start = new Date(trimmedStart);
+          }
         }
       }
+
+      // Whatever is left of the current event, if anything, is placed.
+      if (eventEndTime > event.start.getTime()) {
+        activeEventIndexes.push(finalEvents.length);
+        finalEvents.push(event);
+      }
+
+      /*
+       * The sweep that used to run HERE — rescanning all of finalEvents for
+       * zero-length and inverted entries after every placement — was O(n^2) on
+       * its own and could never find anything. Every event reaching finalEvents
+       * is length-checked at the moment it is pushed, and the only field mutated
+       * afterwards is `end` in the trim branch above, which drops the event on
+       * the spot when it collapses.
+       */
     }
 
     /*
@@ -1699,16 +1755,14 @@ export default class LayerUtil {
      * audit H2). Downstream consumers (getEvents id assignment, the schedule
      * service's current/next selection) expect events in start order.
      */
-    finalEvents.sort((a: CalendarEvent, b: CalendarEvent) => {
-      if (OneUptimeDate.isBefore(a.start, b.start)) {
-        return -1;
-      }
-
-      if (OneUptimeDate.isAfter(a.start, b.start)) {
-        return 1;
-      }
+    const keptEvents: PriorityCalendarEvents[] = finalEvents.filter(
+      (_event: PriorityCalendarEvents, index: number) => {
+        return !removedEventIndexes.has(index);
+      },
+    );
 
-      return 0;
+    keptEvents.sort((a: CalendarEvent, b: CalendarEvent) => {
+      return a.start.getTime() - b.start.getTime();
     });
 
     // convert PriorityCalendarEvents to CalendarEvents
@@ -1716,7 +1770,7 @@ export default class LayerUtil {
     const calendarEvents: CalendarEvent[] = [];
     let id: number = 1;
 
-    for (const event of finalEvents) {
+    for (const event of keptEvents) {
       const calendarEvent: CalendarEvent = {
         ...event,
         id: id,

package/Types/OnCallDutyPolicy/OnCallDutyPolicyStatus.ts

@@ -3,6 +3,19 @@ enum OnCallDutyPolicyStatus {
   Started = "Started",
   Executing = "Executing",
   Completed = "Execution Completed",
+  /*
+   * Terminal, like Completed, but the policy walked every escalation rule
+   * without paging a single person — typically because every rule targeted an
+   * on-call schedule that had nobody on call. Kept distinct from Completed
+   * because the two used to be indistinguishable: an incident that notified
+   * nobody closed out with the same green "Execution Completed" as one that
+   * successfully paged the on-call engineer, so a policy could silently notify
+   * no one indefinitely.
+   *
+   * `status` is a varchar column (not a Postgres enum type), so adding this
+   * value needs no schema migration.
+   */
+  CompletedWithNoNotifications = "Execution Completed - No One Notified",
   Error = "Error",
 }
 

package/Types/OnCallDutyPolicy/ScheduleShiftUtil.ts

@@ -49,13 +49,55 @@ export interface CurrentAndNextShift {
 }
 
 /*
- * Two coverage segments are considered part of the same continuous shift when
- * the gap between them is below this threshold. LayerUtil starts each following
- * segment exactly one second after the previous one ends, so anything within a
- * couple of minutes is "touching"; anything larger is a genuine off-hours gap
- * (a restriction window closing, a rotation with no fallback layer, etc.).
+ * Why a schedule currently has (or does not have) somebody on call. The four
+ * states are mutually exclusive and ordered by how early the misconfiguration
+ * happens, so a caller can render the most specific remedy it knows about:
+ *
+ * - NoLayers      the schedule has no layers at all -> "add a layer"
+ * - NoUsers       layers exist but nobody is assigned to any of them, so the
+ *                 engine emits zero events and NOBODY is ever on call. This is
+ *                 a permanent 100% gap, not an off-hours one, and it needs its
+ *                 own remedy ("assign users") — telling someone to widen their
+ *                 active hours here would be wrong.
+ * - UncoveredNow  users are assigned and shifts exist, but none covers `now`
+ * - Covered       somebody is on call at this instant
  */
-const CONTIGUITY_TOLERANCE_SECONDS: number = 90;
+export enum ScheduleCoverageStatus {
+  NoLayers = "NoLayers",
+  NoUsers = "NoUsers",
+  UncoveredNow = "UncoveredNow",
+  Covered = "Covered",
+}
+
+export interface ScheduleCoverageState {
+  status: ScheduleCoverageStatus;
+  current: OnCallShift | null;
+  next: OnCallShift | null;
+  gaps: Array<CoverageGap>;
+  // Total uncovered seconds inside [now, windowEnd].
+  uncoveredSeconds: number;
+  /*
+   * Fraction of [now, windowEnd] that somebody is on call for, 0..1. 0 for both
+   * NoLayers and NoUsers; 1 for a schedule with no gaps at all.
+   */
+  coverageRatio: number;
+}
+
+/*
+ * Two coverage segments belong to the same continuous shift when the hole
+ * between them is at or below this threshold. LayerUtil starts each following
+ * segment exactly one second after the previous one ends (Layer.ts advances
+ * with addRemoveSeconds(end, 1)) and the multi-layer priority merge leaves
+ * seams of the same ±1s magnitude, so a few seconds of slack is all that is
+ * needed to absorb the engine's own artifacts.
+ *
+ * This used to be 90 seconds, which silently swallowed genuine sub-minute
+ * coverage holes — a schedule whose layers were misaligned by a minute
+ * reported full coverage. Anything above the engine artifact is a real hole and
+ * is now reported; callers that consider very short holes to be display noise
+ * filter them at the render layer (see getCoverageGaps' minimumGapSeconds).
+ */
+const CONTIGUITY_TOLERANCE_SECONDS: number = 5;
 
 export default class ScheduleShiftUtil {
   /*
@@ -191,6 +233,7 @@ export default class ScheduleShiftUtil {
     shifts: Array<OnCallShift>,
     windowStart: Date,
     windowEnd: Date,
+    options?: { minimumGapSeconds?: number | undefined } | undefined,
   ): Array<CoverageGap> {
     const gaps: Array<CoverageGap> = [];
 
@@ -199,18 +242,24 @@ export default class ScheduleShiftUtil {
     }
 
     /*
-     * A gap only "counts" when it is longer than the contiguity tolerance, so
+     * A hole only "counts" as a gap when it is longer than the threshold, so
      * the one-second boundaries LayerUtil leaves between segments never show up
-     * as spurious coverage holes.
+     * as spurious coverage holes. Callers that treat short holes as display
+     * noise (rather than as a misconfiguration worth reporting) raise
+     * minimumGapSeconds instead of relying on the detector to hide them.
      */
+    const minimumGapSeconds: number =
+      options?.minimumGapSeconds === undefined
+        ? CONTIGUITY_TOLERANCE_SECONDS
+        : options.minimumGapSeconds;
+
     const isRealGap: (start: Date, end: Date) => boolean = (
       start: Date,
       end: Date,
     ): boolean => {
       return (
         OneUptimeDate.isAfter(end, start) &&
-        OneUptimeDate.getDifferenceInSeconds(end, start) >
-          CONTIGUITY_TOLERANCE_SECONDS
+        OneUptimeDate.getDifferenceInSeconds(end, start) > minimumGapSeconds
       );
     };
 
@@ -254,4 +303,100 @@ export default class ScheduleShiftUtil {
 
     return gaps;
   }
+
+  /*
+   * The single source of truth for "does this schedule have anybody on call,
+   * and if not, why not". Every surface that renders coverage derives its state
+   * from here rather than inventing its own condition.
+   *
+   * This exists because the UI used to gate its gap warnings on
+   * `assignedUserCount > 0` — a condition that is exactly INVERTED, since zero
+   * assigned users IS the total-gap state. The one screen that would have said
+   * "nobody is on call" was therefore the one screen that never rendered.
+   * Returning an explicit status makes that class of mistake impossible: a
+   * caller must handle NoUsers, it cannot accidentally fall into "covered".
+   */
+  public static getCoverageState(data: {
+    layerCount: number;
+    assignedUserCount: number;
+    shifts: Array<OnCallShift>;
+    now: Date;
+    windowEnd: Date;
+    minimumGapSeconds?: number | undefined;
+  }): ScheduleCoverageState {
+    const { current, next }: CurrentAndNextShift = this.getCurrentAndNextShift(
+      data.shifts,
+      data.now,
+    );
+
+    const gaps: Array<CoverageGap> = this.getCoverageGaps(
+      data.shifts,
+      data.now,
+      data.windowEnd,
+      { minimumGapSeconds: data.minimumGapSeconds },
+    );
+
+    const uncoveredSeconds: number = gaps.reduce(
+      (total: number, gap: CoverageGap) => {
+        return total + OneUptimeDate.getDifferenceInSeconds(gap.end, gap.start);
+      },
+      0,
+    );
+
+    let status: ScheduleCoverageStatus = ScheduleCoverageStatus.Covered;
+
+    if (data.layerCount <= 0) {
+      status = ScheduleCoverageStatus.NoLayers;
+    } else if (data.assignedUserCount <= 0) {
+      status = ScheduleCoverageStatus.NoUsers;
+    } else if (!current) {
+      status = ScheduleCoverageStatus.UncoveredNow;
+    }
+
+    /*
+     * Test the window's ORDER explicitly rather than inferring it from the sign
+     * of the difference: OneUptimeDate.getDifferenceInSeconds returns an
+     * ABSOLUTE value, so an inverted window (windowEnd before now) yields a
+     * positive windowSeconds. Combined with getCoverageGaps bailing out on such
+     * a window and returning no gaps, the ratio then computed to a confident
+     * 1 — the function whose entire job is to surface missing coverage would
+     * report 100% covered. Fail to 0, never to "everything is fine".
+     */
+    const hasUsableWindow: boolean = OneUptimeDate.isBefore(
+      data.now,
+      data.windowEnd,
+    );
+
+    const windowSeconds: number = hasUsableWindow
+      ? OneUptimeDate.getDifferenceInSeconds(data.windowEnd, data.now)
+      : 0;
+
+    /*
+     * A schedule with no layers, or with layers but nobody assigned to them,
+     * can never put anyone on call — its coverage is 0 by definition, whatever
+     * shifts a caller happened to pass in. Deriving the ratio purely from those
+     * shifts would let a stale set report "100% covered" next to "no layers
+     * configured".
+     */
+    const canEverCover: boolean =
+      status !== ScheduleCoverageStatus.NoLayers &&
+      status !== ScheduleCoverageStatus.NoUsers;
+
+    const coverageRatio: number =
+      !hasUsableWindow || !canEverCover
+        ? 0
+        : Math.min(
+            1,
+            Math.max(0, (windowSeconds - uncoveredSeconds) / windowSeconds),
+          );
+
+    return {
+      status,
+      current,
+      next,
+      gaps,
+      uncoveredSeconds,
+      coverageRatio,
+    };
+  }
 }