@oneuptime/common 12.0.30 → 12.0.32

package/Tests/Utils/Slo/SloEvaluation.test.ts

@@ -0,0 +1,171 @@
+import fs from "fs";
+import path from "path";
+import { describe, expect, test } from "@jest/globals";
+import {
+  SLO_CURRENT_BURN_RATE_WINDOW_MINUTES,
+  SLO_EVALUATION_CADENCE_MINUTES,
+} from "../../../Utils/Slo/SloEvaluation";
+
+/*
+ * The SLO cadence constants.
+ *
+ * These two numbers were prose before they were code — the worker owned them
+ * and the dashboard described them in words ("evaluated every few minutes",
+ * "1x spends the budget exactly over the window") without naming the lookback
+ * the headline burn rate is measured over. Naming them once was the fix, and
+ * each carries a claim about a number that lives somewhere else:
+ *
+ *   - the burn-rate window is "deliberately equal to the default fast-burn
+ *     rule's long window, so the tile and that rule move together", and
+ *   - the cadence is how often a due SLO is re-evaluated.
+ *
+ * Nothing makes either claim fail to compile. The seeded rules are written by
+ * ServiceLevelObjectiveService as plain literals, so someone retuning the
+ * fast-burn default there would leave an overview tile silently measuring a
+ * different span from the rule it is meant to agree with — the two would
+ * disagree on screen with no error anywhere.
+ *
+ * The defaults are read as text because seeding them is a database write
+ * behind a full SLO create, which is not what is under test here.
+ */
+
+const SLO_SERVICE_SOURCE: string = fs.readFileSync(
+  path.join(
+    __dirname,
+    "../../../Server/Services/ServiceLevelObjectiveService.ts",
+  ),
+  "utf8",
+);
+
+/*
+ * The literal block for one seeded rule, so "Fast burn" and "Slow burn"
+ * cannot be confused for one another — they differ only in their numbers.
+ */
+function seededRuleBlock(ruleName: string): string {
+  const start: number = SLO_SERVICE_SOURCE.indexOf(`name: "${ruleName}"`);
+
+  expect(start).toBeGreaterThan(-1);
+
+  const end: number = SLO_SERVICE_SOURCE.indexOf("}", start);
+  expect(end).toBeGreaterThan(start);
+
+  return SLO_SERVICE_SOURCE.slice(start, end);
+}
+
+function minutesFieldIn(block: string, field: string): number {
+  const match: RegExpMatchArray | null = block.match(
+    new RegExp(`${field}:\\s*(\\d+)`),
+  );
+
+  expect(match).not.toBeNull();
+
+  return Number(match![1]);
+}
+
+describe("SLO evaluation cadence constants", () => {
+  describe("the values themselves", () => {
+    /*
+     * Both are used as minutes and multiplied out to seconds by their
+     * callers, so a zero would ask for a zero-length lookback and a
+     * fractional value would land the query on a boundary no bucket starts
+     * on.
+     */
+    test("both are positive whole numbers of minutes", () => {
+      for (const value of [
+        SLO_EVALUATION_CADENCE_MINUTES,
+        SLO_CURRENT_BURN_RATE_WINDOW_MINUTES,
+      ]) {
+        expect(Number.isInteger(value)).toBe(true);
+        expect(value).toBeGreaterThan(0);
+      }
+    });
+
+    /*
+     * A burn rate measured over a span shorter than the gap between
+     * evaluations would be recomputed from data the worker has not refreshed,
+     * so the tile would repeat itself and call it a new reading.
+     */
+    test("the burn-rate lookback is at least one evaluation apart", () => {
+      expect(SLO_CURRENT_BURN_RATE_WINDOW_MINUTES).toBeGreaterThanOrEqual(
+        SLO_EVALUATION_CADENCE_MINUTES,
+      );
+    });
+  });
+
+  /*
+   * The claim in the doc comment, checked against the thing it is a claim
+   * about. If the fast-burn default is ever retuned, this fails here rather
+   * than as two numbers quietly disagreeing on the SLO overview.
+   */
+  describe("the tile and the default fast-burn rule move together", () => {
+    test("the burn-rate window equals the fast-burn rule's long window", () => {
+      expect(
+        minutesFieldIn(seededRuleBlock("Fast burn"), "longWindowInMinutes"),
+      ).toBe(SLO_CURRENT_BURN_RATE_WINDOW_MINUTES);
+    });
+
+    /*
+     * The fast-burn short window is the tightest span the worker is ever
+     * asked to answer for. Evaluating less often than that would leave it
+     * reading a window that has already closed.
+     */
+    test("the evaluation cadence keeps up with the fast-burn short window", () => {
+      expect(
+        minutesFieldIn(seededRuleBlock("Fast burn"), "shortWindowInMinutes"),
+      ).toBeGreaterThanOrEqual(SLO_EVALUATION_CADENCE_MINUTES);
+    });
+
+    /*
+     * Slow burn is the deliberately longer pair. Pinned only as an ordering
+     * against fast burn: if the two ever crossed over, the names would be
+     * backwards and the rule an operator reaches for in an incident would be
+     * the slower of the two.
+     */
+    test("slow burn is genuinely slower than fast burn", () => {
+      const fast: string = seededRuleBlock("Fast burn");
+      const slow: string = seededRuleBlock("Slow burn");
+
+      expect(minutesFieldIn(slow, "longWindowInMinutes")).toBeGreaterThan(
+        minutesFieldIn(fast, "longWindowInMinutes"),
+      );
+      expect(minutesFieldIn(slow, "shortWindowInMinutes")).toBeGreaterThan(
+        minutesFieldIn(fast, "shortWindowInMinutes"),
+      );
+    });
+  });
+
+  /*
+   * Both constants exist so the worker and the UI read the same number. A
+   * caller that inlined the value instead would drift the moment the constant
+   * changed, which is the exact failure the constants were introduced to end.
+   */
+  describe("everything reads the shared constants rather than its own copy", () => {
+    const WORKER_SOURCE: string = fs.readFileSync(
+      path.join(
+        __dirname,
+        "../../../../App/FeatureSet/Workers/Jobs/Slo/EvaluateSlos.ts",
+      ),
+      "utf8",
+    );
+
+    test("the evaluation worker imports both from here", () => {
+      expect(WORKER_SOURCE).toContain("SLO_CURRENT_BURN_RATE_WINDOW_MINUTES");
+      expect(WORKER_SOURCE).toContain("SLO_EVALUATION_CADENCE_MINUTES");
+      expect(WORKER_SOURCE).toContain('from "Common/Utils/Slo/SloEvaluation"');
+    });
+
+    test("the SLO overview reads the window from here too", () => {
+      const overview: string = fs.readFileSync(
+        path.join(
+          __dirname,
+          "../../../../App/FeatureSet/Dashboard/src/Pages/Slo/View/Index.tsx",
+        ),
+        "utf8",
+      );
+
+      expect(overview).toContain(
+        'import { SLO_CURRENT_BURN_RATE_WINDOW_MINUTES } from "Common/Utils/Slo/SloEvaluation"',
+      );
+    });
+  });
+});

package/Tests/Utils/Slug.test.ts

@@ -1,4 +1,5 @@
-import Slug from "../../Utils/Slug";
+import Slug, { SLUG_SUFFIX_LENGTH } from "../../Utils/Slug";
+import ColumnLength from "../../Types/Database/ColumnLength";
 
 describe("Slug.getSlug()", () => {
   test("should return empty string, if name is empty ", () => {
@@ -21,3 +22,62 @@ describe("Slug.getSlug()", () => {
     );
   });
 });
+
+/*
+ * The ceiling exists because the create path THROWS on an oversized value
+ * rather than truncating it (DatabaseService.checkMaxLengthOfFields), and slug
+ * sources are routinely wider than the slug column they feed: Incident.title
+ * is varchar(500) against a varchar(100) slug. DatabaseService.generateSlug
+ * passes the destination column's declared width in.
+ */
+describe("Slug.getSlug() — clamped to a destination column", () => {
+  const LONG_NAME: string = "a very long incident title indeed ".repeat(10);
+
+  test("leaves a name that already fits alone", () => {
+    expect(Slug.getSlug("short name", ColumnLength.Slug)).toMatch(
+      /^short-name-[\d]{10}$/,
+    );
+  });
+
+  test("fits the result inside the ceiling", () => {
+    expect(
+      Slug.getSlug(LONG_NAME, ColumnLength.Slug).length,
+    ).toBeLessThanOrEqual(ColumnLength.Slug);
+  });
+
+  test("cuts the readable half and keeps the unique tail whole", () => {
+    const slug: string = Slug.getSlug(LONG_NAME, ColumnLength.Slug);
+
+    expect(slug.substring(slug.length - SLUG_SUFFIX_LENGTH)).toMatch(
+      /^-[\d]{10}$/,
+    );
+    expect(slug.startsWith("a-very-long-incident-title-indeed")).toBe(true);
+  });
+
+  test("leaves no dash dangling where the cut fell", () => {
+    /*
+     * 44 puts the ceiling exactly on the dash after the second "indeed",
+     * which is the case that would otherwise read `...indeed--0123456789`.
+     */
+    expect(Slug.getSlug(LONG_NAME, 45)).not.toMatch(/--[\d]{10}$/);
+
+    /* Every nearby ceiling, so the case above is not the only one covered. */
+    for (let ceiling: number = 20; ceiling <= 100; ceiling++) {
+      const slug: string = Slug.getSlug(LONG_NAME, ceiling);
+
+      expect(slug.length).toBeLessThanOrEqual(ceiling);
+      expect(slug).not.toMatch(/--[\d]{10}$/);
+    }
+  });
+
+  test("still answers with a random name for a null source", () => {
+    const slug: string = Slug.getSlug(null, ColumnLength.Slug);
+
+    expect(slug).toMatch(/^[a-z0-9-]+-[\d]{10}$/);
+    expect(slug.length).toBeLessThanOrEqual(ColumnLength.Slug);
+  });
+
+  test("still answers with an empty string for an empty name", () => {
+    expect(Slug.getSlug("", ColumnLength.Slug)).toEqual("");
+  });
+});

package/Tests/jest.setup.ts

@@ -1,4 +1,5 @@
 import "@testing-library/jest-dom";
+import { configure } from "@testing-library/react";
 import { jest } from "@jest/globals";
 import { TextEncoder, TextDecoder } from "util";
 import { webcrypto, randomUUID } from "crypto";
@@ -31,3 +32,21 @@ Object.defineProperty(window, "scrollTo", {
   value: jest.fn(),
   writable: true,
 });
+
+/*
+ * Testing Library waits a default of one second for findBy/waitFor. That is a
+ * generous budget for a state update and a hopeless one for a React.lazy
+ * boundary: the first component to render LazyMarkdownViewer has to resolve
+ * the dynamic import and put MarkdownViewer (plus its mermaid mock) through
+ * ts-jest before any assertion on the markdown text can pass. Locally that is
+ * ~400 ms; on a CI runner with the other shard workers competing for the same
+ * cores it goes past a second, and the test fails having rendered the Suspense
+ * fallback -- a timeout wearing the costume of a missing element.
+ *
+ * ~20 components reach the viewer through that wrapper (FeedItem, EventItem,
+ * Detail, BaseModelTable and the rest), so this is a whole class of flake
+ * rather than one test, and it belongs here rather than at one call site.
+ * Five seconds is still short enough that a genuinely broken assertion fails
+ * promptly instead of sitting out the 60 s testTimeout.
+ */
+configure({ asyncUtilTimeout: 5000 });

package/Types/Date.ts

@@ -253,6 +253,45 @@ export default class OneUptimeDate {
     return `${this.getDateAsLocalDayMonthString(date)}, ${this.getLocalTimeString(date, { includeMinutes: false })}:00`;
   }
 
+  /**
+   * "02 Mar, 14:30" — a day-qualified wall clock, for chart axes whose
+   * buckets are finer than an hour but whose window is long enough that a
+   * bare "14:30" would name more than one instant.
+   */
+  public static getDateAsLocalDayMonthTimeString(
+    date: Date | string,
+    options?: { includeSeconds?: boolean | undefined },
+  ): string {
+    date = this.fromString(date);
+
+    return `${this.getDateAsLocalDayMonthString(date)}, ${this.getLocalTimeString(
+      date,
+      { includeSeconds: options?.includeSeconds ?? false },
+    )}`;
+  }
+
+  /**
+   * Minutes `date` sits ahead of UTC in the current timezone. Callers use it
+   * to detect a DST transition inside a window: an offset that DROPS across
+   * the window means the clock went back, and a wall-clock reading in that
+   * hour names two different instants.
+   */
+  public static getTimezoneOffsetInMinutes(date: Date | string): number {
+    return this.inCurrentTimezone(date).utcOffset();
+  }
+
+  /**
+   * The current timezone's abbreviation AT `date` — "BST" in summer, "GMT"
+   * in winter. The only thing that separates the two 01:00s on the day the
+   * clocks go back, so chart axes append it when a window straddles one.
+   */
+  public static getLocalZoneAbbr(date: Date | string): string {
+    return this.getZoneAbbrByTimezone(
+      this.getCurrentTimezone(),
+      this.fromString(date),
+    );
+  }
+
   /**
    * A compact "Mar 1, 14:30" (or "Mar 1, 2:30 PM") label for one instant, used
    * where a whole window has to fit on a button - the time range picker above

package/Types/Monitor/SnmpMonitor/NetworkTopology.ts

@@ -57,6 +57,25 @@ export type NetworkTopologyDeviceRole =
   | "host"
   | "unknown";
 
+/*
+ * The silhouette a node is drawn with on the topology map.
+ *
+ * It lives here, next to the roles, rather than in the renderer that owns
+ * the geometry, because a project's device roles are configurable
+ * (NetworkDeviceRole) and each one stores the shape it is drawn with. The
+ * renderer re-exports this type, so every existing import of it still
+ * resolves to exactly this union.
+ */
+export type NetworkTopologyNodeShape =
+  | "circle"
+  | "rounded-square"
+  | "diamond"
+  | "triangle"
+  | "hexagon"
+  | "tower"
+  | "cylinder"
+  | "rect";
+
 /*
  * Why a device is drawn with no links.
  *
@@ -100,6 +119,48 @@ export interface NetworkTopologyNode {
    * name one — readers must treat both the same way.
    */
   role?: NetworkTopologyDeviceRole | undefined;
+  /*
+   * The project's OWN role for this node, from the configurable
+   * NetworkDeviceRole table (Network > Settings > Device Roles).
+   *
+   * `role` above is the built-in vocabulary the classifier speaks and can
+   * only ever be one of the twelve values in NetworkTopologyDeviceRole.
+   * A project may rename those roles or add roles of its own ("PoS
+   * Terminal", "SD-WAN Edge"), and neither survives that union — so the
+   * four fields here carry the configured answer alongside it.
+   *
+   * They are additive and every one of them is optional: a payload built
+   * before this existed, or for a project with no roles configured, simply
+   * omits them and every reader falls back to `role` exactly as before.
+   * When present they WIN, because they are what the operator configured.
+   *
+   * `roleKey` is the role's stable key — the built-in key ("switch") for a
+   * built-in role however it has been renamed, or a derived key for a
+   * custom one. It is what the legend groups by and what search matches.
+   */
+  roleKey?: string | undefined;
+  // The configured display name, e.g. "Edge Router" for a renamed "router".
+  roleLabel?: string | undefined;
+  // The configured silhouette. Falls back to the built-in shape for `role`.
+  roleShape?: NetworkTopologyNodeShape | undefined;
+  /*
+   * Whether devices of this role sit at the top of the network. Load-bearing:
+   * the tiered and radial layouts band by it, so a custom role can be placed
+   * at core level without the layout having to recognise its name.
+   */
+  isCoreLayerRole?: boolean | undefined;
+  /*
+   * Whether devices of this role are worth walking with SNMP. Read by the
+   * adopt-a-neighbour flow to decide whether it opens on SNMP polling or on
+   * a monitor.
+   */
+  isSnmpWalkableRole?: boolean | undefined;
+  /*
+   * The NetworkDeviceRole row's id, so a form can preselect the role the map
+   * already shows without resolving the key itself. Absent when the project
+   * has no row for this role.
+   */
+  roleId?: string | undefined;
   interfacesUp?: number | undefined;
   interfacesDown?: number | undefined;
   // Extra device identity for search and the detail panel (managed nodes).