@oneuptime/common 12.0.34 → 13.0.1

package/Tests/Server/EnvironmentConfigValkey.test.ts

@@ -0,0 +1,227 @@
+import { afterEach, describe, expect, it, jest } from "@jest/globals";
+
+/*
+ * How the cache/queue settings are read.
+ *
+ * They are named VALKEY_* since 13.0.0. The REDIS_* names they shipped under
+ * for years are still read as a deprecated fallback, and that fallback is the
+ * ONLY reason an existing self-hosted config.env keeps working across the
+ * upgrade -- `npm run update` deliberately does not rewrite it. Nothing here is
+ * cosmetic: if the fallback breaks, every install that has not hand-edited its
+ * config.env silently drops to the built-in defaults (host "redis", password
+ * "password") and cannot authenticate to its own cache.
+ *
+ * EnvironmentConfig reads process.env at module load, so every case sets the
+ * environment, resets the module registry and imports afresh.
+ */
+
+interface EnvironmentConfigShape {
+  RedisHostname: string;
+  RedisPort: { toNumber: () => number };
+  RedisDb: number;
+  RedisUsername: string;
+  RedisPassword: string;
+  RedisTlsCa: string | undefined;
+  RedisTlsCert: string | undefined;
+  RedisTlsKey: string | undefined;
+  RedisTlsSentinelMode: boolean;
+  ShouldRedisTlsEnable: boolean;
+  RedisIPFamily: number;
+}
+
+const SUFFIXES: Array<string> = [
+  "HOST",
+  "PORT",
+  "DB",
+  "USERNAME",
+  "PASSWORD",
+  "IP_FAMILY",
+  "TLS_CA",
+  "TLS_CERT",
+  "TLS_KEY",
+  "TLS_SENTINEL_MODE",
+];
+
+const MANAGED_KEYS: Array<string> = SUFFIXES.flatMap((suffix: string) => {
+  return [`VALKEY_${suffix}`, `REDIS_${suffix}`];
+});
+
+const originalEnv: NodeJS.ProcessEnv = { ...process.env };
+
+async function load(
+  overrides: Record<string, string | undefined>,
+): Promise<EnvironmentConfigShape> {
+  for (const key of MANAGED_KEYS) {
+    delete process.env[key];
+  }
+
+  for (const [key, value] of Object.entries(overrides)) {
+    if (value === undefined) {
+      delete process.env[key];
+    } else {
+      process.env[key] = value;
+    }
+  }
+
+  jest.resetModules();
+
+  return (await import(
+    "../../Server/EnvironmentConfig"
+  )) as unknown as EnvironmentConfigShape;
+}
+
+afterEach(() => {
+  process.env = { ...originalEnv };
+  jest.resetModules();
+});
+
+describe("cache settings read VALKEY_* first", () => {
+  it("reads every setting from its VALKEY_ name", async () => {
+    const config: EnvironmentConfigShape = await load({
+      VALKEY_HOST: "cache.internal",
+      VALKEY_PORT: "6380",
+      VALKEY_DB: "3",
+      VALKEY_USERNAME: "alice",
+      VALKEY_PASSWORD: "sekret",
+      VALKEY_IP_FAMILY: "6",
+      VALKEY_TLS_CA: "ca-pem",
+      VALKEY_TLS_CERT: "cert-pem",
+      VALKEY_TLS_KEY: "key-pem",
+      VALKEY_TLS_SENTINEL_MODE: "true",
+    });
+
+    expect(config.RedisHostname).toBe("cache.internal");
+    expect(config.RedisPort.toNumber()).toBe(6380);
+    expect(config.RedisDb).toBe(3);
+    expect(config.RedisUsername).toBe("alice");
+    expect(config.RedisPassword).toBe("sekret");
+    expect(config.RedisIPFamily).toBe(6);
+    expect(config.RedisTlsCa).toBe("ca-pem");
+    expect(config.RedisTlsCert).toBe("cert-pem");
+    expect(config.RedisTlsKey).toBe("key-pem");
+    expect(config.RedisTlsSentinelMode).toBe(true);
+  });
+});
+
+describe("the deprecated REDIS_* names still work", () => {
+  /*
+   * This is the upgrade case: a config.env written before the rename, never
+   * touched, mounted into a container built after it.
+   */
+  it("reads every setting from its REDIS_ name when that is all there is", async () => {
+    const config: EnvironmentConfigShape = await load({
+      REDIS_HOST: "cache.internal",
+      REDIS_PORT: "6380",
+      REDIS_DB: "3",
+      REDIS_USERNAME: "alice",
+      REDIS_PASSWORD: "sekret",
+      REDIS_IP_FAMILY: "6",
+      REDIS_TLS_CA: "ca-pem",
+      REDIS_TLS_CERT: "cert-pem",
+      REDIS_TLS_KEY: "key-pem",
+      REDIS_TLS_SENTINEL_MODE: "true",
+    });
+
+    expect(config.RedisHostname).toBe("cache.internal");
+    expect(config.RedisPort.toNumber()).toBe(6380);
+    expect(config.RedisDb).toBe(3);
+    expect(config.RedisUsername).toBe("alice");
+    expect(config.RedisPassword).toBe("sekret");
+    expect(config.RedisIPFamily).toBe(6);
+    expect(config.RedisTlsCa).toBe("ca-pem");
+    expect(config.RedisTlsCert).toBe("cert-pem");
+    expect(config.RedisTlsKey).toBe("key-pem");
+    expect(config.RedisTlsSentinelMode).toBe(true);
+  });
+
+  it("prefers the VALKEY_ name when both are set", async () => {
+    const config: EnvironmentConfigShape = await load({
+      VALKEY_HOST: "new.internal",
+      REDIS_HOST: "old.internal",
+      VALKEY_PASSWORD: "new-secret",
+      REDIS_PASSWORD: "old-secret",
+    });
+
+    expect(config.RedisHostname).toBe("new.internal");
+    expect(config.RedisPassword).toBe("new-secret");
+  });
+
+  /*
+   * The single sharpest edge in the whole rename. docker-compose.base.yml lists
+   * every VALKEY_* name, and Compose materialises an unset variable as an EMPTY
+   * STRING rather than leaving it undefined -- so inside our containers the new
+   * name is always *defined*. A `??` fallback would therefore pick the empty new
+   * name over the operator's real old one and fall through to the defaults,
+   * with no error. `||` is what makes this case work.
+   */
+  it("falls back past an empty VALKEY_ value, as compose always sets one", async () => {
+    const config: EnvironmentConfigShape = await load({
+      VALKEY_HOST: "",
+      REDIS_HOST: "cache.internal",
+      VALKEY_PASSWORD: "",
+      REDIS_PASSWORD: "sekret",
+      VALKEY_PORT: "",
+      REDIS_PORT: "6380",
+      VALKEY_USERNAME: "",
+      REDIS_USERNAME: "alice",
+    });
+
+    expect(config.RedisHostname).toBe("cache.internal");
+    expect(config.RedisPassword).toBe("sekret");
+    expect(config.RedisPort.toNumber()).toBe(6380);
+    expect(config.RedisUsername).toBe("alice");
+  });
+
+  /*
+   * TLS is derived from three variables, so an uneven fallback would not throw
+   * -- it would quietly flip the connection to plaintext.
+   */
+  it("still enables TLS from a REDIS_TLS_CA alone", async () => {
+    const config: EnvironmentConfigShape = await load({
+      REDIS_TLS_CA: "ca-pem",
+    });
+
+    expect(config.ShouldRedisTlsEnable).toBe(true);
+  });
+
+  it("still enables TLS from a REDIS_TLS_CERT and REDIS_TLS_KEY pair", async () => {
+    const config: EnvironmentConfigShape = await load({
+      REDIS_TLS_CERT: "cert-pem",
+      REDIS_TLS_KEY: "key-pem",
+    });
+
+    expect(config.ShouldRedisTlsEnable).toBe(true);
+  });
+
+  it("leaves TLS off when nothing is configured under either name", async () => {
+    const config: EnvironmentConfigShape = await load({});
+
+    expect(config.ShouldRedisTlsEnable).toBe(false);
+  });
+});
+
+describe("defaults when neither name is set", () => {
+  /*
+   * The compose service is called `valkey` now, but this default deliberately
+   * stays `redis`: it is only reached when NEITHER variable is set, which never
+   * happens in our own compose or Helm. What it covers is hand-written
+   * Kubernetes manifests, a bare `docker run` and third-party compose files,
+   * where the Service has been called `redis` for years. Compose users are fine
+   * either way -- the valkey service answers to `redis` through a network alias.
+   */
+  it("keeps the historical redis hostname", async () => {
+    const config: EnvironmentConfigShape = await load({});
+
+    expect(config.RedisHostname).toBe("redis");
+  });
+
+  it("keeps the rest of the historical defaults", async () => {
+    const config: EnvironmentConfigShape = await load({});
+
+    expect(config.RedisPort.toNumber()).toBe(6379);
+    expect(config.RedisDb).toBe(0);
+    expect(config.RedisUsername).toBe("default");
+    expect(config.RedisIPFamily).toBe(4);
+    expect(config.RedisTlsSentinelMode).toBe(false);
+  });
+});

package/Tests/Server/Infrastructure/Postgres/AddMacAddressToNetworkDeviceMigration.test.ts

@@ -0,0 +1,365 @@
+import { describe, expect, test } from "@jest/globals";
+import fs from "fs";
+import path from "path";
+import {
+  MigrationInterface,
+  QueryRunner,
+  getMetadataArgsStorage,
+} from "typeorm";
+import { ColumnMetadataArgs } from "typeorm/metadata-args/ColumnMetadataArgs";
+import NetworkDevice from "../../../../Models/DatabaseModels/NetworkDevice";
+import ColumnLength from "../../../../Types/Database/ColumnLength";
+import ColumnType from "../../../../Types/Database/ColumnType";
+import SchemaMigrations from "../../../../Server/Infrastructure/Postgres/SchemaMigrations/Index";
+import { AddMacAddressToNetworkDevice1791700000000 } from "../../../../Server/Infrastructure/Postgres/SchemaMigrations/1791700000000-AddMacAddressToNetworkDevice";
+
+/*
+ * The migration behind #3489: NetworkDevice.macAddress.
+ *
+ * Two things are worth pinning about it, and neither is the SQL — the
+ * statement was generated rather than written, and the schema-drift job
+ * already proves it matches the entity.
+ *
+ * The first is NULLABILITY, because it carries meaning here rather than
+ * just permissiveness. NULL is not "unset pending a backfill": it means "no
+ * MAC declared and none learned yet", which is the value every existing
+ * device should hold. A DEFAULT would restate the whole fleet as having a
+ * MAC it does not have — and, worse, would stop the ARP learner from ever
+ * filling the column, because it only ever writes into an EMPTY value.
+ *
+ * The second is REGISTRATION: an import that never reaches the default
+ * export array leaves the migration unregistered, and it silently never
+ * runs — the column is missing in production while every local database
+ * migrated by hand looks fine.
+ *
+ * The statements are also EXECUTED against a fake QueryRunner, not only
+ * read as text. A file read as one blob cannot tell up() from down(): a
+ * migration whose up() DROPPED the column and whose down() ADDED it
+ * contains both statements and satisfies every `toContain` written against
+ * the blob.
+ */
+
+const MIGRATION_TIMESTAMP: string = "1791700000000";
+
+const MIGRATION_FILE_NAME: string = `${MIGRATION_TIMESTAMP}-AddMacAddressToNetworkDevice.ts`;
+
+const MIGRATION_CLASS_NAME: string = `AddMacAddressToNetworkDevice${MIGRATION_TIMESTAMP}`;
+
+const MIGRATION_DIRECTORY: string = path.join(
+  __dirname,
+  "../../../../Server/Infrastructure/Postgres/SchemaMigrations",
+);
+
+const MIGRATION_PATH: string = path.join(
+  MIGRATION_DIRECTORY,
+  MIGRATION_FILE_NAME,
+);
+
+const SOURCE: string = fs.readFileSync(MIGRATION_PATH, "utf8");
+
+const COLUMN: string = "macAddress";
+
+const ADD_COLUMN_SQL: string = `ALTER TABLE "NetworkDevice" ADD "${COLUMN}" character varying(100)`;
+
+const DROP_COLUMN_SQL: string = `ALTER TABLE "NetworkDevice" DROP COLUMN "${COLUMN}"`;
+const FLAG_COLUMN: string = "isMacAddressLearned";
+const ADD_FLAG_SQL: string = `ALTER TABLE "NetworkDevice" ADD "${FLAG_COLUMN}" boolean DEFAULT false`;
+const DROP_FLAG_SQL: string = `ALTER TABLE "NetworkDevice" DROP COLUMN "${FLAG_COLUMN}"`;
+
+/*
+ * Hoisted so the literals are not the object of a member expression, which
+ * wrap-regex and Prettier cannot agree on.
+ */
+const ADD_STATEMENTS: RegExp = /`(ALTER TABLE [^`]*ADD "[^"]+"[^`]*)`/g;
+const ADDED_COLUMNS: RegExp = /ADD "(\w+)"/g;
+const DROPPED_COLUMNS: RegExp = /DROP COLUMN "(\w+)"/g;
+const TOUCHED_TABLES: RegExp = /ALTER TABLE "(\w+)"/g;
+const EVERY_STATEMENT: RegExp =
+  /`((?:ALTER TABLE|CREATE INDEX|DROP INDEX|UPDATE)[^`]+)`/g;
+const CLASS_TIMESTAMP: RegExp = /(\d{13})$/;
+
+type MakeQueryRunnerResult = {
+  runner: QueryRunner;
+  statements: Array<string>;
+};
+
+type MakeQueryRunnerFunction = () => MakeQueryRunnerResult;
+
+const makeQueryRunner: MakeQueryRunnerFunction = (): MakeQueryRunnerResult => {
+  const statements: Array<string> = [];
+
+  const query: (...args: Array<unknown>) => Promise<undefined> = (
+    ...args: Array<unknown>
+  ): Promise<undefined> => {
+    statements.push(String(args[0]));
+    return Promise.resolve(undefined);
+  };
+
+  return {
+    runner: { query } as unknown as QueryRunner,
+    statements,
+  };
+};
+
+function typeOrmColumn(): ColumnMetadataArgs | undefined {
+  return getMetadataArgsStorage().columns.find((column: ColumnMetadataArgs) => {
+    return column.target === NetworkDevice && column.propertyName === COLUMN;
+  });
+}
+
+describe("the column it adds", () => {
+  test("NetworkDevice gains macAddress as a varchar(100)", () => {
+    expect(SOURCE).toContain(ADD_COLUMN_SQL);
+  });
+
+  /*
+   * See the header: NULL is a meaningful value, so the column may not
+   * arrive with a DEFAULT or a NOT NULL.
+   */
+  test("the column is given no default and is nullable", () => {
+    const addStatements: Array<string> = [
+      ...SOURCE.matchAll(ADD_STATEMENTS),
+    ].map((match: RegExpMatchArray): string => {
+      return match[1] as string;
+    });
+
+    expect(addStatements.length).toBe(2);
+    for (const statement of addStatements) {
+      expect(statement).not.toContain("NOT NULL");
+    }
+    /*
+     * The MAC itself has no default: NULL means "not known", which is a
+     * real state. The provenance flag beside it defaults to false, so
+     * every existing row reads "typed" - a MAC nobody learned is nobody's
+     * to correct.
+     */
+    expect(addStatements[0]).not.toContain("DEFAULT");
+    expect(addStatements[1]).toContain("DEFAULT false");
+  });
+
+  test("it touches nothing beyond the device table", () => {
+    const touchedTables: Set<string> = new Set<string>(
+      [...SOURCE.matchAll(TOUCHED_TABLES)].map(
+        (match: RegExpMatchArray): string => {
+          return match[1] as string;
+        },
+      ),
+    );
+
+    expect([...touchedTables]).toEqual(["NetworkDevice"]);
+  });
+
+  /*
+   * No backfill, and deliberately: there is nothing to fill it FROM. The
+   * MAC of a device that was never walked is not stored anywhere, and the
+   * ARP learner fills the column on the next router walk for every device
+   * it can — a pass here would only write nulls that are already there.
+   */
+  test("it does not backfill", () => {
+    expect(SOURCE).not.toContain("UPDATE ");
+  });
+});
+
+describe("up and down are symmetric", () => {
+  test("down drops exactly what up adds, and nothing else", () => {
+    const added: Array<string> = [...SOURCE.matchAll(ADDED_COLUMNS)].map(
+      (match: RegExpMatchArray): string => {
+        return match[1] as string;
+      },
+    );
+    const dropped: Array<string> = [...SOURCE.matchAll(DROPPED_COLUMNS)].map(
+      (match: RegExpMatchArray): string => {
+        return match[1] as string;
+      },
+    );
+
+    expect(added).toEqual([COLUMN, FLAG_COLUMN]);
+    expect([...added].sort()).toEqual([...dropped].sort());
+  });
+
+  /*
+   * A stray semicolon would split one queryRunner.query() into two, and a
+   * newline inside a statement means the template literal wrapped.
+   */
+  test("every statement is a complete, single statement", () => {
+    const statements: Array<RegExpMatchArray> = [
+      ...SOURCE.matchAll(EVERY_STATEMENT),
+    ];
+
+    expect(statements.length).toBe(4);
+    for (const statement of statements) {
+      expect(statement[1]).not.toContain(";");
+      expect(statement[1]).not.toContain("\n");
+      expect(statement[1]!.trimStart()).toBe(statement[1]);
+    }
+  });
+});
+
+describe("executing it", () => {
+  /*
+   * `toEqual` on the whole statement list rather than `toContain` on any
+   * one of them, because "nothing else" is half the claim: no UPDATE pass,
+   * no second table quietly altered, no index built on the way past.
+   */
+  test("up() adds the column, and does nothing else", async () => {
+    const { runner, statements } = makeQueryRunner();
+
+    await new AddMacAddressToNetworkDevice1791700000000().up(runner);
+
+    expect(statements).toEqual([ADD_COLUMN_SQL, ADD_FLAG_SQL]);
+  });
+
+  /*
+   * The direction matters as much as the SQL. Asserted through an actual
+   * call to down(), so a migration that added the column in down() and
+   * dropped it in up() — which would drop the column out of every deployed
+   * database on the next boot — fails here rather than passing a text
+   * search that finds both statements somewhere in the file.
+   */
+  test("down() drops exactly the column up() added, and nothing else", async () => {
+    const { runner, statements } = makeQueryRunner();
+
+    await new AddMacAddressToNetworkDevice1791700000000().down(runner);
+
+    expect(statements).toEqual([DROP_FLAG_SQL, DROP_COLUMN_SQL]);
+  });
+
+  /*
+   * TypeORM calls `up` and `down` by name. A rename to anything else — a
+   * refactor that made `up` an `upgrade`, a helper method left on the
+   * class — leaves a migration the runner will not run, which is the same
+   * outcome as not writing it.
+   */
+  test("is a MigrationInterface whose two steps are still named up and down", () => {
+    const migration: MigrationInterface =
+      new AddMacAddressToNetworkDevice1791700000000();
+
+    expect(typeof migration.up).toBe("function");
+    expect(typeof migration.down).toBe("function");
+    expect(
+      Object.getOwnPropertyNames(
+        AddMacAddressToNetworkDevice1791700000000.prototype,
+      ).sort(),
+    ).toEqual(["constructor", "down", "up"]);
+  });
+
+  /*
+   * The migration and the model have to describe the same column. Two
+   * files, one schema: the migration is what the deployed database gets,
+   * the model is what every query assumes it got. Read off the SQL up()
+   * actually ran, so the comparison is against the statement that reaches
+   * Postgres.
+   */
+  test("the SQL it runs says the same thing about the column that the model does", async () => {
+    const { runner, statements } = makeQueryRunner();
+
+    await new AddMacAddressToNetworkDevice1791700000000().up(runner);
+
+    const addColumn: string = statements[0] ?? "";
+
+    expect(addColumn).toContain(
+      `ADD "${COLUMN}" character varying(${ColumnLength.ShortText})`,
+    );
+    expect(typeOrmColumn()?.options.type).toBe(ColumnType.ShortText);
+    expect(typeOrmColumn()?.options.length).toBe(ColumnLength.ShortText);
+
+    expect(addColumn).not.toContain("NOT NULL");
+    expect(typeOrmColumn()?.options.nullable).toBe(true);
+
+    expect(addColumn).not.toContain("DEFAULT");
+    expect(typeOrmColumn()?.options.default).toBeUndefined();
+  });
+});
+
+describe("the migration runs", () => {
+  test("it is registered", () => {
+    const index: string = fs.readFileSync(
+      path.join(MIGRATION_DIRECTORY, "Index.ts"),
+      "utf8",
+    );
+
+    expect(index).toContain(
+      `from "./${MIGRATION_TIMESTAMP}-AddMacAddressToNetworkDevice"`,
+    );
+    expect(index).toContain(`${MIGRATION_CLASS_NAME},`);
+  });
+
+  /*
+   * ...and registered for real, not just mentioned in the file: an import
+   * that never reaches the default-export array leaves the migration
+   * unregistered, and it silently never runs.
+   */
+  test("it is in the exported migration list", () => {
+    expect(SchemaMigrations).toContain(
+      AddMacAddressToNetworkDevice1791700000000,
+    );
+  });
+
+  /*
+   * TypeORM records applied migrations by the `name` property, not the
+   * file name. A mismatch re-runs the migration on every boot.
+   */
+  test("its declared name matches its class name", () => {
+    expect(new AddMacAddressToNetworkDevice1791700000000().name).toBe(
+      MIGRATION_CLASS_NAME,
+    );
+    expect(AddMacAddressToNetworkDevice1791700000000.name).toBe(
+      MIGRATION_CLASS_NAME,
+    );
+  });
+
+  /*
+   * ...and the timestamp in the class name is the one on disk. A class
+   * renamed without renaming its file (or two migrations landing on the
+   * same timestamp — this directory has had that happen twice) runs in an
+   * order nobody declared.
+   */
+  test("exactly one file on disk carries its timestamp, and it is this one", () => {
+    const matching: Array<string> = fs
+      .readdirSync(MIGRATION_DIRECTORY)
+      .filter((file: string): boolean => {
+        return file.startsWith(`${MIGRATION_TIMESTAMP}-`);
+      });
+
+    expect(matching).toEqual([MIGRATION_FILE_NAME]);
+  });
+
+  /*
+   * Migrations run in array order, and one landing BELOW a migration that
+   * has already run applies out of order. Only the durable half is asserted
+   * here — nothing registered BEFORE this one carries a later timestamp.
+   * "It is the newest" belongs to whichever migration is currently newest
+   * and lives in SchemaMigrationsOrdering.test.ts.
+   */
+  test("its timestamp sorts after every migration registered before it", () => {
+    const position: number = SchemaMigrations.indexOf(
+      AddMacAddressToNetworkDevice1791700000000,
+    );
+
+    expect(position).toBeGreaterThan(-1);
+
+    const earlierTimestamps: Array<number> = [];
+
+    for (const migrationClass of SchemaMigrations.slice(0, position)) {
+      const match: RegExpMatchArray | null = (
+        migrationClass as { name: string }
+      ).name.match(CLASS_TIMESTAMP);
+
+      if (match) {
+        earlierTimestamps.push(Number(match[1]));
+      }
+    }
+
+    /*
+     * Math.max() of an empty list is -Infinity, which every timestamp
+     * beats. Prove the list was actually enumerated before leaning on its
+     * maximum. (InitialMigration carries no timestamp, hence "greater
+     * than", not "equal to", the slice length.)
+     */
+    expect(earlierTimestamps.length).toBeGreaterThan(100);
+
+    expect(Number(MIGRATION_TIMESTAMP)).toBeGreaterThan(
+      Math.max(...earlierTimestamps),
+    );
+  });
+});

package/Tests/Server/Infrastructure/Postgres/CustomFieldValueMappingMigration.test.ts

@@ -64,8 +64,25 @@ const MAPPING_COLUMNS: ReadonlyArray<string> = [
   "mapFromCustomFieldName",
 ];
 
-/** The `<timestamp>-<Name>.ts` prefix TypeORM orders migrations by. */
-const MIGRATION_TIMESTAMP_PREFIX: RegExp = /^(\d+)-/;
+/*
+ * The timestamp read off the CLASS name, which is what TypeORM actually sorts
+ * by and what the migrations table records. Null for the one registered class
+ * that predates the convention (InitialMigration).
+ */
+const MIGRATION_CLASS_TIMESTAMP: RegExp = /(\d{10,})$/;
+
+const OWN_CLASS_NAME: string = "AddCustomFieldValueMapping1791600000000";
+
+type TimestampOfClassNameFunction = (className: string) => number | null;
+
+const timestampOfClassName: TimestampOfClassNameFunction = (
+  className: string,
+): number | null => {
+  const match: RegExpExecArray | null =
+    MIGRATION_CLASS_TIMESTAMP.exec(className);
+
+  return match ? parseInt(match[1]!, 10) : null;
+};
 
 /*
  * What TypeORM's metadata storage keys entities by: the class itself. Only
@@ -174,29 +191,51 @@ describe("the value-mapping migration", () => {
 
   /*
    * TypeORM orders migrations by the timestamp in the class name, not by the
-   * order of the array. A timestamp below one already registered would run
-   * this migration before migrations that shipped earlier — harmless here, but
-   * the convention in this directory is a monotonic timestamp and breaking it
-   * makes the ordering unreadable.
+   * position in SchemaMigrations/Index.ts. A timestamp BELOW one already
+   * registered would run this migration ahead of migrations that shipped
+   * before it — against a schema that does not yet have the columns those
+   * migrations added.
+   *
+   * This used to assert the timestamp was the newest in the whole DIRECTORY,
+   * which is a claim any later migration falsifies: the next one to land
+   * (AddMacAddressToNetworkDevice, 1791700000000) turned it red without going
+   * anywhere near the value-mapping columns it guards. The migrations
+   * registered AFTER this one run after it whichever way round they are, and
+   * are none of this test's business; the ones registered BEFORE it are the
+   * queue it must not jump.
+   *
+   * Note this is deliberately not a claim that the whole registry is
+   * monotonic. It is not — eleven adjacent pairs are already inverted, from
+   * branches that landed out of order — and asserting otherwise here would be
+   * failing this suite for somebody else's history.
    */
-  test("its timestamp is the newest in the directory", () => {
-    const timestamps: Array<number> = fs
-      .readdirSync(MIGRATIONS_DIRECTORY)
-      .map((fileName: string) => {
-        return MIGRATION_TIMESTAMP_PREFIX.exec(fileName);
-      })
-      .filter((match: RegExpExecArray | null): match is RegExpExecArray => {
-        return Boolean(match);
-      })
-      .map((match: RegExpExecArray) => {
-        return parseInt(match[1]!, 10);
-      });
-
-    const ownTimestamp: number = parseInt(
-      MIGRATION_TIMESTAMP_PREFIX.exec(path.basename(MIGRATION_PATH))![1]!,
-      10,
+  test("its timestamp keeps it behind every migration registered before it", () => {
+    const registered: Array<string> = SchemaMigrations.map(
+      (migration: { name: string }): string => {
+        return migration.name;
+      },
     );
 
-    expect(Math.max(...timestamps)).toBe(ownTimestamp);
+    const ownIndex: number = registered.indexOf(OWN_CLASS_NAME);
+
+    /*
+     * Asserted rather than assumed: indexOf returning -1 would silently make
+     * the slice below empty and the whole test vacuous. Registration itself
+     * has its own test above; this is about the failure MODE of this one.
+     */
+    expect(ownIndex).toBeGreaterThan(0);
+
+    const ownTimestamp: number = timestampOfClassName(OWN_CLASS_NAME)!;
+
+    const laterThanUs: Array<string> = registered
+      .slice(0, ownIndex)
+      .filter((className: string): boolean => {
+        const timestamp: number | null = timestampOfClassName(className);
+
+        return timestamp !== null && timestamp >= ownTimestamp;
+      });
+
+    // Named, not counted, so a failure says which migration it would jump.
+    expect(laterThanUs).toEqual([]);
   });
 });