@oneuptime/common 12.0.7 → 12.0.9

package/Types/Monitor/SnmpMonitor/NetworkTopology.ts

@@ -13,10 +13,16 @@
 export type NetworkTopologyNodeStatus = "up" | "down" | "unknown";
 
 /*
- * Which source(s) reported a link — a discovery protocol, or the bridge
- * forwarding database (endpoint attachment).
+ * Which source(s) reported a link — a discovery protocol, the bridge
+ * forwarding database (endpoint attachment), or a person.
+ *
+ * "manual" is a NetworkDeviceLink an operator drew: a cable neither protocol
+ * can see, because one end has discovery disabled, does not speak LLDP or
+ * CDP, or is monitored by ping alone. It is a protocol like the others so a
+ * hand-drawn link and a later-discovered one MERGE into a single edge
+ * carrying both, rather than doubling the line on the map.
  */
-export type NetworkTopologyLinkProtocol = "lldp" | "cdp" | "fdb";
+export type NetworkTopologyLinkProtocol = "lldp" | "cdp" | "fdb" | "manual";
 
 /*
  * What a node represents. Older payloads carry no kind — readers should
@@ -26,6 +32,60 @@ export type NetworkTopologyLinkProtocol = "lldp" | "cdp" | "fdb";
  */
 export type NetworkTopologyNodeKind = "device" | "unmanaged" | "endpoint";
 
+/*
+ * What the node DOES on the network, as opposed to what we know about it
+ * (`kind`). Derived server-side from the identity SNMP and the discovery
+ * protocols already report — sysObjectId, sysDescr, model/platform, and
+ * finally the hostname — because a map on which a router, a switch and a
+ * camera are the same circle cannot be read at a glance.
+ *
+ * "unknown" is a real answer, not a failure: guessing a role from thin
+ * evidence is worse than drawing a neutral node, so the classifier only
+ * commits when the evidence names a product family or says the word.
+ */
+export type NetworkTopologyDeviceRole =
+  | "router"
+  | "switch"
+  | "firewall"
+  | "wirelessAccessPoint"
+  | "loadBalancer"
+  | "server"
+  | "storage"
+  | "printer"
+  | "camera"
+  | "phone"
+  | "host"
+  | "unknown";
+
+/*
+ * Why a device is drawn with no links.
+ *
+ * "The router is not linked to any device" is a report we could previously
+ * only answer with a shrug — the map showed an isolated box and nothing about
+ * which of the several possible causes was the real one. These fields turn
+ * that into a sentence: discovery never ran, or it ran and the device
+ * reported nothing, or it reported neighbours that matched nothing we manage
+ * (and here is what they called themselves).
+ *
+ * Present on managed device nodes only; absent on older payloads.
+ */
+export interface NetworkTopologyNodeDiagnostics {
+  /*
+   * False when the device's interface walk is off. LLDP and CDP ride along
+   * with that walk, so a device with it disabled can never report a
+   * neighbour, however well it speaks either protocol.
+   */
+  isNeighborDiscoveryEnabled?: boolean | undefined;
+  // How many neighbour entries the device's last poll reported.
+  reportedNeighborCount: number;
+  /*
+   * What the unresolved neighbours called themselves. This is the actionable
+   * half: an operator reading "advertised OLD-CORE-SW1" knows immediately
+   * that a device was renamed, which no amount of "no links found" conveys.
+   */
+  unmatchedNeighborIdentifiers: Array<string>;
+}
+
 export interface NetworkTopologyNode {
   // Device id for managed nodes; a synthetic "unmanaged:<key>" id otherwise.
   id: string;
@@ -34,6 +94,12 @@ export interface NetworkTopologyNode {
   status: NetworkTopologyNodeStatus;
   // Missing on older payloads — derive from isManaged.
   kind?: NetworkTopologyNodeKind | undefined;
+  /*
+   * What the node does on the network (router, switch, firewall, ...).
+   * Missing on older payloads, and "unknown" when the evidence did not
+   * name one — readers must treat both the same way.
+   */
+  role?: NetworkTopologyDeviceRole | undefined;
   interfacesUp?: number | undefined;
   interfacesDown?: number | undefined;
   // Extra device identity for search and the detail panel (managed nodes).
@@ -51,6 +117,8 @@ export interface NetworkTopologyNode {
   ipAddress?: string | undefined;
   classification?: string | undefined;
   vlanId?: number | undefined;
+  // Why this device has no links. Managed device nodes only.
+  diagnostics?: NetworkTopologyNodeDiagnostics | undefined;
 }
 
 /*
@@ -79,6 +147,15 @@ export interface NetworkTopologyEdge {
   // Operational data at each end, when the endpoint interface is known.
   fromInterface?: NetworkTopologyEdgeEndpoint | undefined;
   toInterface?: NetworkTopologyEdgeEndpoint | undefined;
+  /*
+   * Health for a link that has no interface counters of its own — a manual
+   * link with a Monitor bound to it. Readers prefer real interface data and
+   * fall back to this, so a discovered link never loses its measured state
+   * to a monitor's summary of it.
+   */
+  monitorState?: "up" | "down" | undefined;
+  // Operator-supplied label, set only on manual links.
+  name?: string | undefined;
 }
 
 export default interface NetworkTopology {

package/Types/NetworkDevice/NetworkDeviceMonitoringMethod.ts

@@ -0,0 +1,55 @@
+/*
+ * How a NetworkDevice's health is established.
+ *
+ * The network product was built around SNMP: a device is a thing an assigned
+ * probe walks on a schedule, and everything downstream — the status pill, the
+ * site rollup, the topology map — reads freshness off `lastSeenAt`, which only
+ * a successful walk ever stamps.
+ *
+ * Plenty of real gear cannot be walked. Consumer APs, PDUs, cameras, anything
+ * with SNMP disabled by policy: an operator tracks those with an ordinary Ping
+ * or IP monitor. They are as real a part of the network as the switch they
+ * hang off, and before this existed they could not be recorded as devices at
+ * all — so they were absent from the site hierarchy and from the topology map,
+ * which is what issue #3023 is about.
+ *
+ * `Monitor` is that second answer: no probe, no credentials, no polling; the
+ * bound Monitor's status IS the device's status, stamped through the same
+ * bridge that already stamps SNMP devices watched by a Network Device monitor.
+ *
+ * Stored as free text on the column (the SnmpVersion precedent), so parse it
+ * through `NetworkDeviceMonitoringMethodUtil.parse` rather than comparing the
+ * raw column: rows written before this existed hold NULL and must read as
+ * `Snmp`, which is what they are.
+ */
+export enum NetworkDeviceMonitoringMethod {
+  // An assigned probe walks the device over SNMP on its own schedule.
+  Snmp = "SNMP",
+  // No polling; a bound Monitor (Ping, IP, Port, ...) reports its health.
+  Monitor = "Monitor",
+}
+
+export class NetworkDeviceMonitoringMethodUtil {
+  /*
+   * NULL, empty and anything unrecognised read as Snmp — that is what every
+   * device created before this column existed is, and defaulting a device
+   * into "monitor-backed" would silently stop it being polled.
+   */
+  public static parse(
+    value: string | undefined | null,
+  ): NetworkDeviceMonitoringMethod {
+    if ((value || "").trim().toLowerCase() === "monitor") {
+      return NetworkDeviceMonitoringMethod.Monitor;
+    }
+    return NetworkDeviceMonitoringMethod.Snmp;
+  }
+
+  public static isMonitorBacked(value: string | undefined | null): boolean {
+    return (
+      NetworkDeviceMonitoringMethodUtil.parse(value) ===
+      NetworkDeviceMonitoringMethod.Monitor
+    );
+  }
+}
+
+export default NetworkDeviceMonitoringMethod;

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",
 }