@oneuptime/common 12.0.7 → 12.0.9

package/build/dist/Server/Services/OnCallReadinessService.js

@@ -0,0 +1,1961 @@
+import AlertSeverityService from "./AlertSeverityService";
+import IncidentSeverityService from "./IncidentSeverityService";
+import OnCallDutyPolicyEscalationRuleScheduleService from "./OnCallDutyPolicyEscalationRuleScheduleService";
+import OnCallDutyPolicyEscalationRuleTeamService from "./OnCallDutyPolicyEscalationRuleTeamService";
+import OnCallDutyPolicyEscalationRuleUserService from "./OnCallDutyPolicyEscalationRuleUserService";
+import OnCallDutyPolicyScheduleLayerUserService from "./OnCallDutyPolicyScheduleLayerUserService";
+import OnCallDutyPolicyService from "./OnCallDutyPolicyService";
+import OnCallDutyPolicyUserOverrideService from "./OnCallDutyPolicyUserOverrideService";
+import ProjectService from "./ProjectService";
+import TeamMemberService from "./TeamMemberService";
+import TeamService from "./TeamService";
+import UserCallService from "./UserCallService";
+import UserEmailService from "./UserEmailService";
+import UserNotificationRuleService from "./UserNotificationRuleService";
+import UserPushService from "./UserPushService";
+import UserService from "./UserService";
+import UserSmsService from "./UserSmsService";
+import UserTelegramService from "./UserTelegramService";
+import UserWebhookService from "./UserWebhookService";
+import UserWhatsAppService from "./UserWhatsAppService";
+import InMemoryTTLCache from "../Infrastructure/InMemoryTTLCache";
+import QueryHelper from "../Types/Database/QueryHelper";
+import logger from "../Utils/Logger";
+import Includes from "../../Types/BaseDatabase/Includes";
+import SortOrder from "../../Types/BaseDatabase/SortOrder";
+import { LIMIT_PER_PROJECT } from "../../Types/Database/LimitMax";
+import OneUptimeDate from "../../Types/Date";
+import BadDataException from "../../Types/Exception/BadDataException";
+import NotificationRuleType from "../../Types/NotificationRule/NotificationRuleType";
+import ObjectID from "../../Types/ObjectID";
+/*
+ * "Can this responder actually be paged?" — computed, not configured.
+ *
+ * This is the single place that answers that question, and every readiness surface in
+ * the product renders what it returns. It exists because the question was previously
+ * answered by TeamComplianceService, which answered it wrongly in seven separate ways —
+ * each of which is a real defect with a real missed page behind it, and each of which is
+ * fixed here deliberately rather than incidentally:
+ *
+ *   1. It was opt-in per team and OFF by default, so the common case was no answer at
+ *      all. Readiness here is always computed; there is nothing to switch on.
+ *   2. It was TEAM-SCOPED. A user attached directly to an escalation rule, reached
+ *      through a schedule layer, or substituted in by a user override was never checked —
+ *      which is to say the three ways a responder most often gets paged were invisible.
+ *      resolveResponders below is the union of all four, and the union is the point.
+ *   3. It capped members and users at a bare `limit: 100`, silently truncating a large
+ *      project into a comfortable lie. NOTHING here is capped: every read goes through
+ *      readEveryPage, which pages until the table is exhausted. See the essay on that
+ *      method for why raising the cap instead would have been the same bug with a bigger
+ *      number — a responder who falls off the end of a page is reported in no count, no
+ *      list and no summary, which is indistinguishable from a responder who is fine.
+ *   4. It ignored `ruleType`, so a "when I go off call" rule counted as incident
+ *      coverage. Coverage below is keyed on (userId, ruleType, severityId); a rule for
+ *      the wrong ruleType covers nothing.
+ *   5. It counted only call/SMS/email/push, so a responder whose only method was
+ *      Telegram, WhatsApp or Webhook was reported non-compliant while being perfectly
+ *      reachable. All seven channels count here.
+ *   6. It ran one findBy per severity per user. Every read below is batched with
+ *      Includes(userIds); the query count is constant in the number of responders and
+ *      in the number of severities. It grows only with the number of PAGES of rows that
+ *      come back, which is the unavoidable price of not truncating.
+ *
+ * The seventh defect was that it was read-only prose. This service does not fix that on
+ * its own, but everything it returns is shaped to be acted on: `reasons` are sentences
+ * naming a specific missing thing, and `coverage` is a grid an admin can fix cell by
+ * cell.
+ */
+/**
+ * Ready — every coverage cell either has a rule or is explicitly muted.
+ * PartiallyReady — reachable, but at least one cell falls back.
+ * NotReachable — zero USABLE notification methods; nothing will reach this person.
+ */
+export var ReadinessStatus;
+(function (ReadinessStatus) {
+    ReadinessStatus["Ready"] = "Ready";
+    ReadinessStatus["PartiallyReady"] = "PartiallyReady";
+    ReadinessStatus["NotReachable"] = "NotReachable";
+})(ReadinessStatus || (ReadinessStatus = {}));
+/**
+ * WHY a user is on this policy. A user reached two ways carries both sources, because
+ * removing them from one attachment does not stop them being paged through the other —
+ * an admin looking at an unreachable responder needs to know every door they came in by.
+ */
+export var ResponderSource;
+(function (ResponderSource) {
+    ResponderSource["Direct"] = "Direct";
+    ResponderSource["Team"] = "Team";
+    ResponderSource["Schedule"] = "Schedule";
+    ResponderSource["Override"] = "Override";
+})(ResponderSource || (ResponderSource = {}));
+/**
+ * The seven channels a page can be delivered on. These strings are the same literals the
+ * fallback uses for `channelsUsed` (UserNotificationRuleService.chooseFallbackChannels),
+ * deliberately: an operator reading "notified via fallback (Push, Email)" in an execution
+ * log and "Push, Email" in the readiness table must not have to translate between two
+ * vocabularies for the same thing.
+ */
+export var ReadinessMethodType;
+(function (ReadinessMethodType) {
+    ReadinessMethodType["Push"] = "Push";
+    ReadinessMethodType["Email"] = "Email";
+    ReadinessMethodType["SMS"] = "SMS";
+    ReadinessMethodType["Call"] = "Call";
+    ReadinessMethodType["WhatsApp"] = "WhatsApp";
+    ReadinessMethodType["Telegram"] = "Telegram";
+    ReadinessMethodType["Webhook"] = "Webhook";
+})(ReadinessMethodType || (ReadinessMethodType = {}));
+/*
+ * The bullet used for every redaction. A single shared constant so a test can assert on
+ * the mask without hard-coding a character that is easy to typo into a look-alike (there
+ * are several bullet-ish code points and they are indistinguishable on screen).
+ */
+export const IDENTIFIER_MASK = "•••";
+/**
+ * What SHAPE an identifier has, which is all masking needs to know. Kept separate from
+ * ReadinessMethodType because five of the seven channels mask identically — a phone is a
+ * phone whether it rings, texts or WhatsApps — and collapsing them here means a new
+ * channel cannot arrive with no masking rule at all.
+ */
+export var MaskedIdentifierKind;
+(function (MaskedIdentifierKind) {
+    MaskedIdentifierKind["Email"] = "Email";
+    MaskedIdentifierKind["Phone"] = "Phone";
+    MaskedIdentifierKind["Handle"] = "Handle";
+})(MaskedIdentifierKind || (MaskedIdentifierKind = {}));
+/*
+ * How many trailing digits of a phone number are revealed, and the shortest value that
+ * may have them revealed. The two are deliberately different numbers: revealing the last
+ * four digits of a four-digit value reveals the value, and revealing the last four of a
+ * FIVE-digit value would be a mask in name only. A number has to be longer than what the
+ * mask keeps for the mask to be hiding anything at all, so the floor is "more digits than
+ * we reveal".
+ */
+const REVEALED_PHONE_DIGITS = 4;
+/**
+ * Redact an identifier down to just enough for its owner to recognise it.
+ *
+ * Exported as a free function, and used by this service for every single identifier it
+ * emits, for two reasons. The first is that masking is the one rule in this file that
+ * must never be got wrong even slightly, and a pure function of (string, kind) is
+ * directly unit-testable in a way that "call the service and inspect the summary" is
+ * not. The second is structural: because the ONLY way an identifier reaches a
+ * ReadinessMethod is through this function, the API layer has no unmasked value
+ * available to leak by accident. Bypassing the masking would require deliberately
+ * writing a second query, not merely forgetting a call.
+ *
+ *   Email  jane@example.com  -> j•••@example.com
+ *   Phone  +14155554821      -> +1 ••• ••• 4821
+ *   Handle @jamesbond        -> @ja•••
+ *
+ * The phone rule keeps everything before the last ten digits as the country code, which
+ * is a heuristic rather than a parse — national numbers are ~10 digits nearly
+ * everywhere, so "+1" and "+44" both come out right, and a country whose numbering plan
+ * disagrees loses a cosmetic digit and leaks nothing. Correctness here is measured in
+ * what is HIDDEN, and the last four digits plus the country code is the same disclosure
+ * every bank confirmation screen makes.
+ */
+export const maskIdentifier = (value, kind) => {
+    const trimmed = (value || "").trim();
+    if (!trimmed) {
+        /*
+         * Nothing to mask and nothing to reveal. Returning the bare mask rather than an
+         * empty string keeps the UI cell from collapsing into blank space that reads as
+         * "no method" when a method demonstrably exists.
+         */
+        return IDENTIFIER_MASK;
+    }
+    if (kind === MaskedIdentifierKind.Email) {
+        const atIndex = trimmed.lastIndexOf("@");
+        /*
+         * An address with no "@" is not an address. Rather than guess, fall through to the
+         * handle rule, which is strictly more conservative than the email rule (it reveals
+         * two characters and no domain).
+         */
+        if (atIndex <= 0) {
+            return maskIdentifier(trimmed, MaskedIdentifierKind.Handle);
+        }
+        const localPart = trimmed.substring(0, atIndex);
+        const domain = trimmed.substring(atIndex + 1);
+        return `${localPart.substring(0, 1)}${IDENTIFIER_MASK}@${domain}`;
+    }
+    if (kind === MaskedIdentifierKind.Phone) {
+        const digits = trimmed.replace(/\D/g, "");
+        /*
+         * Note the <=, not <. At exactly four digits the "last four" IS the whole value, so
+         * the old strict comparison handed the number back in full while looking, on the
+         * screen and in a code review, exactly like a mask. Anything at or below the number
+         * of digits we reveal is therefore masked entirely: a value we cannot hide half of
+         * is a value we do not show.
+         */
+        if (digits.length <= REVEALED_PHONE_DIGITS) {
+            return IDENTIFIER_MASK;
+        }
+        const lastFour = digits.substring(digits.length - REVEALED_PHONE_DIGITS);
+        const countryCode = digits.length > 10 ? digits.substring(0, digits.length - 10) : "";
+        const prefix = countryCode ? `+${countryCode} ` : "";
+        return `${prefix}${IDENTIFIER_MASK} ${IDENTIFIER_MASK} ${lastFour}`;
+    }
+    /*
+     * Handles cover Telegram handles, push device names and webhook names. Two characters
+     * is enough for the owner to say "yes, that is my phone" and not enough for anyone
+     * else to say whose phone it is.
+     */
+    const hasLeadingAt = trimmed.startsWith("@");
+    const body = hasLeadingAt ? trimmed.substring(1) : trimmed;
+    return `${hasLeadingAt ? "@" : ""}${body.substring(0, 2)}${IDENTIFIER_MASK}`;
+};
+/*
+ * Which severity list scopes which rule type, and the noun to use when telling an admin
+ * about it. Incident and incident-episode pages are severity-scoped by IncidentSeverity;
+ * alert and alert-episode by AlertSeverity. Getting this pairing wrong is not a cosmetic
+ * error — an alert rule matched against an incident severity id matches nothing at all,
+ * which is exactly the shape of Gap G, where episode default rules were written with a
+ * NULL severity and were therefore invisible and unreachable at the same time.
+ */
+var SeverityKind;
+(function (SeverityKind) {
+    SeverityKind["Incident"] = "Incident";
+    SeverityKind["Alert"] = "Alert";
+})(SeverityKind || (SeverityKind = {}));
+/*
+ * The four rule types a PAGE can arrive under. The two handoff types
+ * (WHEN_USER_GOES_ON_CALL / WHEN_USER_GOES_OFF_CALL) are deliberately absent: they are
+ * courtesy notifications about a shift change, nobody is waiting on them, and counting a
+ * missing one as "not ready" would flood the amber state with users whose paging is
+ * perfectly healthy. Readiness is about pages.
+ */
+const RULE_TYPE_SCOPES = [
+    {
+        ruleType: NotificationRuleType.ON_CALL_EXECUTED_INCIDENT,
+        severityKind: SeverityKind.Incident,
+        subjectNoun: "incidents",
+    },
+    {
+        ruleType: NotificationRuleType.ON_CALL_EXECUTED_INCIDENT_EPISODE,
+        severityKind: SeverityKind.Incident,
+        subjectNoun: "incident episodes",
+    },
+    {
+        ruleType: NotificationRuleType.ON_CALL_EXECUTED_ALERT,
+        severityKind: SeverityKind.Alert,
+        subjectNoun: "alerts",
+    },
+    {
+        ruleType: NotificationRuleType.ON_CALL_EXECUTED_ALERT_EPISODE,
+        severityKind: SeverityKind.Alert,
+        subjectNoun: "alert episodes",
+    },
+];
+/*
+ * Display order for `methods`, and simultaneously the order the fallback would try them
+ * in. Sharing one order means the first entry in the list an admin looks at is the
+ * channel a fallback page would actually arrive on.
+ */
+const METHOD_DISPLAY_ORDER = [
+    ReadinessMethodType.Push,
+    ReadinessMethodType.Email,
+    ReadinessMethodType.SMS,
+    ReadinessMethodType.Call,
+    ReadinessMethodType.WhatsApp,
+    ReadinessMethodType.Telegram,
+    ReadinessMethodType.Webhook,
+];
+const RESPONDER_SOURCE_ORDER = [
+    ResponderSource.Direct,
+    ResponderSource.Team,
+    ResponderSource.Schedule,
+    ResponderSource.Override,
+];
+/*
+ * Most-broken-first. The readiness table is read by somebody looking for a problem, so
+ * the problems sort to the top and the healthy majority sorts out of the way.
+ */
+const STATUS_SORT_RANK = {
+    [ReadinessStatus.NotReachable]: 0,
+    [ReadinessStatus.PartiallyReady]: 1,
+    [ReadinessStatus.Ready]: 2,
+};
+/*
+ * 60 seconds, the same window ProjectService.currentPlanCache uses and for the same
+ * reason: this is computed on page load and on every responder chip render, the inputs
+ * (escalation rules, notification rules, verified methods) change on a human timescale,
+ * and a minute of staleness on "this person has no SMS rule" costs nothing. There is no
+ * cross-process invalidation — each replica holds its own copy — so the TTL is the only
+ * guarantee, which is why it is short.
+ */
+const READINESS_CACHE_TTL_IN_MS = 60 * 1000;
+/*
+ * Rows per page. LIMIT_PER_PROJECT is the largest read the database layer will serve
+ * (DatabaseService clamps anything above it), so it is the biggest page that survives a
+ * round trip, and a bigger page means fewer round trips for the same total.
+ */
+const READ_PAGE_SIZE = LIMIT_PER_PROJECT;
+/*
+ * A ceiling on the number of pages ONE read may take, so a fetcher that keeps returning
+ * full pages — a paging bug, a query whose sort is not total, a table that is genuinely
+ * growing faster than we can read it — cannot spin this service forever holding a
+ * connection. Five million rows is far past any real project; a read that hits it is a
+ * bug report, not a big customer, which is why hitting it is logged as an error AND
+ * reported as isTruncated rather than quietly stopping.
+ */
+const MAX_PAGES_PER_READ = 500;
+/*
+ * Pipe-separated because none of the three components can contain a pipe: user and
+ * severity ids are uuids, and NotificationRuleType's values are fixed English sentences.
+ */
+const buildCoverageKey = (userId, ruleType, severityId) => {
+    return `${userId}|${ruleType}|${severityId}`;
+};
+class OnCallReadinessService {
+    /**
+     * Readiness for every responder a single policy can reach — the union of its direct
+     * users, its teams' members, its schedules' layer users, and anyone an override routes
+     * pages to.
+     */
+    static async getReadinessForPolicy(policyId, projectId) {
+        var _a;
+        const cacheKey = `${projectId.toString()}:policy:${policyId.toString()}`;
+        const cached = this.summaryCache.get(cacheKey);
+        if (cached) {
+            return cached;
+        }
+        /*
+         * Look the policy up rather than letting a bad id fall through. Every query below is
+         * scoped by projectId, so a policy id from another project would return zero
+         * responders — and a summary that says "0 responders, nothing wrong" is the most
+         * dangerous possible answer to "is this policy safe to rely on?".
+         */
+        const policy = await OnCallDutyPolicyService.findOneById({
+            id: policyId,
+            select: {
+                _id: true,
+                projectId: true,
+            },
+            props: {
+                isRoot: true,
+            },
+        });
+        if (!policy || ((_a = policy.projectId) === null || _a === void 0 ? void 0 : _a.toString()) !== projectId.toString()) {
+            throw new BadDataException("On-call duty policy not found");
+        }
+        const summary = await this.computeSummary(projectId, policyId);
+        this.summaryCache.set(cacheKey, summary, READINESS_CACHE_TTL_IN_MS);
+        return summary;
+    }
+    /**
+     * Readiness for every responder reachable through ANY policy in the project. Same
+     * resolution as the per-policy call with the policy filter dropped, so a user who is
+     * ready on one policy and unreachable on another appears exactly once, with the union
+     * of their sources.
+     */
+    static async getReadinessForProject(projectId) {
+        const cacheKey = `${projectId.toString()}:project`;
+        const cached = this.summaryCache.get(cacheKey);
+        if (cached) {
+            return cached;
+        }
+        const summary = await this.computeSummary(projectId, undefined);
+        this.summaryCache.set(cacheKey, summary, READINESS_CACHE_TTL_IN_MS);
+        return summary;
+    }
+    /**
+     * Readiness for a SET of users, at the cost of one user.
+     *
+     * This is the entry point every list-shaped caller must use — a team roster, a
+     * responder table, a page of chips. It exists because the obvious alternative,
+     * `Promise.all(userIds.map(getReadinessForUser))`, is not a small inefficiency but a
+     * different order of cost: each of those calls used to resolve the ENTIRE project's
+     * responder set (six heavy reads) purely to work out one user's `reachedVia`, so a
+     * forty-member team issued several hundred queries where a handful would do, and one
+     * rejected promise threw the whole page away.
+     *
+     * The query count here is constant in the number of users asked about: every read is
+     * `Includes(userIds)` over the whole set, and the membership resolution is targeted at
+     * exactly those users rather than at the project. One user and five hundred users cost
+     * the same round trips — the only thing that grows is the number of PAGES each read
+     * takes, which is a function of how many rows exist, not of how many users were asked
+     * about, and is the price of never truncating.
+     *
+     * Users that are not members of the project are OMITTED rather than thrown for: a
+     * roster read races with somebody being removed from a team, and one departed member
+     * must not blank out the readiness of the other thirty-nine. A caller that needs to
+     * know about the omission should compare the returned userIds with the ones it asked
+     * for.
+     */
+    static async getReadinessForUsers(userIds, projectId) {
+        if (userIds.length === 0) {
+            return [];
+        }
+        const batch = await this.computeReadinessForUsers(userIds, projectId);
+        return batch.readiness;
+    }
+    /**
+     * Readiness for one user, whether or not they are on a policy at all.
+     *
+     * The "whether or not" matters: this is what the add-responder modal calls BEFORE the
+     * user has been attached to anything, which is the only moment at which the mistake is
+     * cheap to fix. Such a user has an empty `reachedVia` and a status computed exactly as
+     * it would be once they are attached.
+     *
+     * A thin wrapper over getReadinessForUsers, deliberately: one code path computes
+     * readiness for a set, and "one" is a set of size one. The only thing this adds is
+     * turning the two ways of getting nothing back — not a member of the project, member
+     * with no User row — into the two different exceptions callers have always seen.
+     */
+    static async getReadinessForUser(userId, projectId) {
+        const batch = await this.computeReadinessForUsers([userId], projectId);
+        /*
+         * User is a GLOBAL model — it is not scoped by project — so without this check any
+         * caller holding a project's credentials could ask for the readiness of an arbitrary
+         * user id and get their name and login email back. Team membership is what "in this
+         * project" means, so that is what is checked, and it is checked BEFORE any other
+         * read is issued (see computeReadinessForUsers), so a caller probing arbitrary user
+         * ids learns nothing at all.
+         */
+        if (!batch.memberUserIds.has(userId.toString())) {
+            throw new BadDataException("User is not a member of this project");
+        }
+        const readiness = batch.readiness[0];
+        if (!readiness) {
+            throw new BadDataException("User not found");
+        }
+        return readiness;
+    }
+    /**
+     * Throw away every cached answer in this process.
+     *
+     * Deliberately coarse — it does not take a projectId — because the cache is keyed
+     * three different ways (project, policy, user) and a write to one notification rule
+     * can invalidate all three at once: the rule's owner, every policy that reaches them,
+     * and the project roll-up. Working out the affected key set would be more code than
+     * the saving is worth when the entries expire in sixty seconds anyway, and a
+     * too-clever invalidation that misses a key is indistinguishable from the stale
+     * readiness this whole service exists to eliminate.
+     *
+     * This is PUBLIC and must actually be CALLED. Until it is, a "Recheck" button re-reads
+     * the same sixty-second-old answer and redraws it unchanged, which reads to an admin
+     * who has just fixed something as "my fix did not work". The exact call sites, all of
+     * which currently do not call it:
+     *
+     *   - UserNotificationRuleService — on create and on delete of a rule (this is the
+     *     write the Recheck button is nearly always chasing).
+     *   - The seven notification-method services (UserEmailService, UserSmsService,
+     *     UserCallService, UserPushService, UserWhatsAppService, UserTelegramService,
+     *     UserWebhookService) — on create, on delete, and on VERIFICATION, which is the
+     *     write that flips a responder from NotReachable to Ready.
+     *   - OnCallDutyPolicyEscalationRuleUserService / ...TeamService / ...ScheduleService
+     *     and OnCallDutyPolicyScheduleLayerUserService — on create and delete, because
+     *     they change who the responder set even contains.
+     *   - OnCallDutyPolicyUserOverrideService — on create, update and delete.
+     *   - TeamMemberService — on create and delete, for the same reason.
+     *   - ProjectService — on any update that touches disableOnCallNotificationFallback or
+     *     the four enable*Notifications switches, since those change every user's status
+     *     at once.
+     *   - IncidentSeverityService / AlertSeverityService — on create and delete, which add
+     *     and remove whole columns of the coverage grid.
+     *   - OnCallReadinessAPI — on an explicit refresh request, so "Recheck" means recheck.
+     *
+     * Note that each replica holds its own copy and clears only its own; the TTL remains
+     * the only cross-process guarantee.
+     */
+    static clearCache() {
+        this.summaryCache.clear();
+        this.userCache.clear();
+    }
+    static async computeSummary(projectId, onCallDutyPolicyId) {
+        const completeness = this.newReadCompleteness();
+        /*
+         * Loaded here rather than inside the per-user pass because the summary itself has to
+         * report isFallbackEnabled even when the responder set is empty — a project with no
+         * responders and the fallback switched off is exactly the project somebody is about
+         * to attach a responder to.
+         */
+        const projectSettings = await this.loadProjectSettings(projectId);
+        const responders = await this.resolveResponders(projectId, onCallDutyPolicyId, completeness);
+        const users = await this.buildReadiness({
+            projectId: projectId,
+            responders: responders,
+            projectSettings: projectSettings,
+            completeness: completeness,
+        });
+        let readyCount = 0;
+        let partiallyReadyCount = 0;
+        let notReachableCount = 0;
+        for (const user of users) {
+            if (user.status === ReadinessStatus.Ready) {
+                readyCount++;
+            }
+            else if (user.status === ReadinessStatus.PartiallyReady) {
+                partiallyReadyCount++;
+            }
+            else {
+                notReachableCount++;
+            }
+        }
+        return {
+            projectId: projectId,
+            onCallDutyPolicyId: onCallDutyPolicyId,
+            readyCount: readyCount,
+            partiallyReadyCount: partiallyReadyCount,
+            notReachableCount: notReachableCount,
+            isFallbackEnabled: !projectSettings.isFallbackDisabled,
+            isTruncated: completeness.isTruncated,
+            users: users,
+        };
+    }
+    /**
+     * The batch computation both public user-shaped entry points share.
+     *
+     * Membership is resolved FIRST and everything else is filtered to the members it
+     * found, which does three jobs with one read: it is the cross-project guard, it is the
+     * source of each user's team list (which is how the Team source is resolved without
+     * expanding the whole project), and it is what makes "user removed mid-request" a
+     * quiet omission rather than an exception.
+     */
+    static async computeReadinessForUsers(userIds, projectId) {
+        const requestedUserIds = this.distinctIds(userIds);
+        const readiness = [];
+        const memberUserIds = new Set();
+        const uncachedUserIds = [];
+        for (const userId of requestedUserIds) {
+            const cached = this.userCache.get(this.userCacheKey(projectId, userId));
+            if (cached) {
+                /*
+                 * Only members are ever written to this cache, so a hit answers the membership
+                 * question too. That matters: re-issuing the membership read for a cached user
+                 * would make a cache hit cost a round trip, which is most of what the cache is
+                 * for.
+                 */
+                memberUserIds.add(userId.toString());
+                readiness.push(cached);
+                continue;
+            }
+            uncachedUserIds.push(userId);
+        }
+        if (uncachedUserIds.length === 0) {
+            return {
+                readiness: this.sortReadiness(readiness),
+                memberUserIds: memberUserIds,
+            };
+        }
+        const completeness = this.newReadCompleteness();
+        const teamIdsByUserId = await this.loadProjectMembership(projectId, uncachedUserIds, completeness);
+        const memberIds = uncachedUserIds.filter((userId) => {
+            return teamIdsByUserId.has(userId.toString());
+        });
+        for (const memberId of memberIds) {
+            memberUserIds.add(memberId.toString());
+        }
+        if (memberIds.length === 0) {
+            return {
+                readiness: this.sortReadiness(readiness),
+                memberUserIds: memberUserIds,
+            };
+        }
+        const projectSettings = await this.loadProjectSettings(projectId);
+        const responders = await this.resolveRespondersForUsers({
+            projectId: projectId,
+            userIds: memberIds,
+            teamIdsByUserId: teamIdsByUserId,
+            completeness: completeness,
+        });
+        const computed = await this.buildReadiness({
+            projectId: projectId,
+            responders: responders,
+            projectSettings: projectSettings,
+            completeness: completeness,
+        });
+        for (const one of computed) {
+            /*
+             * A truncated read can only make a user look WORSE here — a rule that did not
+             * arrive reads as a missing rule, a method that did not arrive as a missing method
+             * — so the answer is safe to RETURN. It is not safe to cache for a minute, and the
+             * reason is the asymmetry with the summary: ReadinessSummary carries isTruncated,
+             * so a cached truncated summary is still telling the truth about itself, whereas
+             * UserReadiness carries no such field and a cached one would be an unlabelled false
+             * amber sitting on somebody's card for sixty seconds. Recomputing is cheap next to
+             * teaching admins that amber means nothing.
+             */
+            if (!completeness.isTruncated) {
+                this.userCache.set(this.userCacheKey(projectId, one.userId), one, READINESS_CACHE_TTL_IN_MS);
+            }
+            readiness.push(one);
+        }
+        return {
+            readiness: this.sortReadiness(readiness),
+            memberUserIds: memberUserIds,
+        };
+    }
+    static userCacheKey(projectId, userId) {
+        return `${projectId.toString()}:user:${userId.toString()}`;
+    }
+    static newReadCompleteness() {
+        return {
+            isTruncated: false,
+        };
+    }
+    /**
+     * Read a whole table, one page at a time, folding each page as it arrives.
+     *
+     * This is the single most important method in the file, because the alternative it
+     * replaces — one findBy capped at LIMIT_PER_PROJECT — is not a performance choice but
+     * a correctness one, and it fails in the worst available direction. UserNotificationRule
+     * rows grow as users x (2 x incidentSeverities + 2 x alertSeverities) x verified
+     * methods, so a five thousand responder project with eight severities of each kind and
+     * two methods each holds around 340,000 of them. A single capped read returns the first
+     * 10,000 — roughly a hundred and fifty users' worth, in whatever order the database
+     * felt like — and every other responder is then scored against ZERO rules. The same
+     * shape on a responder-producing read (team member expansion, schedule layers) is worse
+     * still: those users never enter the map at all, so they appear in no count, no list and
+     * no "needs attention" section. The feature reports them as though they do not exist.
+     *
+     * Raising the cap does not fix that; it moves it to a slightly larger project and makes
+     * it harder to notice. Paging does fix it, at the cost of one round trip per full page,
+     * which is a price worth paying to never quietly lie about who can be paged.
+     *
+     * Three details that are load-bearing rather than incidental:
+     *
+     *   - Pages are folded by the CALLER as they arrive, not accumulated and returned. The
+     *     coverage read would otherwise materialise all 340,000 rows at once purely to
+     *     collapse them into a map of a few thousand entries.
+     *   - Every read is sorted, with `_id` ascending as the final tiebreak. OFFSET paging
+     *     over an unordered — or non-totally-ordered — query may return the same row twice
+     *     and skip another, and the default sort here would be `createdAt DESC`, which is
+     *     emphatically not unique when a migration wrote a project's default rules in one
+     *     transaction.
+     *   - Hitting MAX_PAGES_PER_READ sets isTruncated AND logs an error. A truncation that
+     *     is merely logged is invisible to the person reading the readiness table, and a
+     *     truncation that is merely flagged is invisible to whoever has to work out why.
+     */
+    static async readEveryPage(data) {
+        const sort = Object.assign(Object.assign({}, (data.sort || {})), { _id: SortOrder.Ascending });
+        let skip = 0;
+        for (let page = 0; page < MAX_PAGES_PER_READ; page++) {
+            const rows = await data.service.findBy({
+                /*
+                 * A fresh shallow copy per page: findBy hands the query object to the permission
+                 * layer, which is free to add its own predicates to it, and a query that
+                 * accumulated them across pages would silently narrow as it went.
+                 */
+                query: Object.assign({}, data.query),
+                select: data.select,
+                sort: sort,
+                limit: READ_PAGE_SIZE,
+                skip: skip,
+                props: {
+                    isRoot: true,
+                },
+            });
+            data.consumePage(rows);
+            if (rows.length < READ_PAGE_SIZE) {
+                return;
+            }
+            skip += rows.length;
+        }
+        data.completeness.isTruncated = true;
+        logger.error(`OnCallReadinessService stopped reading ${data.description} for project ${data.projectId.toString()} after ${MAX_PAGES_PER_READ} pages of ${READ_PAGE_SIZE} rows. The readiness answer for this project is INCOMPLETE: responders may be missing from it entirely, and its counts understate the number of people who cannot be paged.`);
+    }
+    /**
+     * The effective responder set, deduped on userId, with every source a user was reached
+     * by.
+     *
+     * This mirrors OnCallDutyPolicyEscalationRuleService.startRuleExecution, which is the
+     * runtime's own answer to "who does this page". Any divergence between the two is a
+     * lie in the UI: a readiness table that omits a user the runtime pages is worse than
+     * no table, because it actively certifies a gap as covered. Three deliberate
+     * alignments with the runtime:
+     *
+     *   - Team members are NOT filtered by hasAcceptedInvitation, because
+     *     TeamMemberService.getUsersInTeam does not filter either. A member who never
+     *     accepted their invite still gets paged, so they still have to be checked.
+     *   - Schedule layer users are taken WHOLE, not sampled for who is on call right now.
+     *     Readiness is a property of the roster, not of this instant; a user in next
+     *     week's rotation with no notification rule is a page that will be missed next
+     *     week, and that is precisely what this is for.
+     *   - Overrides contribute the user pages are ROUTED TO, not the user being covered
+     *     for. During an override the covered user is not paged at all, while the
+     *     substitute is — and the substitute may not be attached to the policy by any
+     *     other means, which makes them the single most likely responder to be silently
+     *     unreachable.
+     */
+    static async resolveResponders(projectId, onCallDutyPolicyId, completeness) {
+        const responders = new Map();
+        const addResponder = (userId, source, teamId) => {
+            if (!userId) {
+                return;
+            }
+            const key = userId.toString();
+            let existing = responders.get(key);
+            if (!existing) {
+                existing = {
+                    sources: new Set(),
+                    teamIds: new Set(),
+                };
+                responders.set(key, existing);
+            }
+            existing.sources.add(source);
+            if (teamId) {
+                existing.teamIds.add(teamId.toString());
+            }
+        };
+        // 1. Users attached directly to an escalation rule.
+        const directQuery = {
+            projectId: projectId,
+        };
+        if (onCallDutyPolicyId) {
+            directQuery.onCallDutyPolicyId = onCallDutyPolicyId;
+        }
+        await this.readEveryPage({
+            description: "escalation rule users",
+            projectId: projectId,
+            completeness: completeness,
+            service: OnCallDutyPolicyEscalationRuleUserService,
+            query: directQuery,
+            select: {
+                _id: true,
+                userId: true,
+            },
+            consumePage: (rows) => {
+                for (const row of rows) {
+                    addResponder(row.userId, ResponderSource.Direct);
+                }
+            },
+        });
+        // 2. Teams attached to an escalation rule, expanded to their members.
+        const teamQuery = {
+            projectId: projectId,
+        };
+        if (onCallDutyPolicyId) {
+            teamQuery.onCallDutyPolicyId = onCallDutyPolicyId;
+        }
+        const escalationTeams = [];
+        await this.readEveryPage({
+            description: "escalation rule teams",
+            projectId: projectId,
+            completeness: completeness,
+            service: OnCallDutyPolicyEscalationRuleTeamService,
+            query: teamQuery,
+            select: {
+                _id: true,
+                teamId: true,
+            },
+            consumePage: (rows) => {
+                escalationTeams.push(...rows);
+            },
+        });
+        const teamIds = this.distinctIds(escalationTeams.map((team) => {
+            return team.teamId;
+        }));
+        if (teamIds.length > 0) {
+            /*
+             * ONE paged read for every team on the policy, not one per team. This is the N+1
+             * that made TeamComplianceService unusable on a project of any size — and the page
+             * loop is what keeps the fix from re-introducing the truncation it replaced, since
+             * five thousand users across three teams is fifteen thousand membership rows and
+             * the old single read returned ten thousand of them.
+             */
+            await this.readEveryPage({
+                description: "team members of escalation rule teams",
+                projectId: projectId,
+                completeness: completeness,
+                service: TeamMemberService,
+                query: {
+                    projectId: projectId,
+                    teamId: new Includes(teamIds),
+                },
+                select: {
+                    _id: true,
+                    userId: true,
+                    /*
+                     * WHICH team, not merely that a team was involved. One extra column on a read
+                     * that already runs, and it is what lets the readiness table be filtered down
+                     * to a team without a second pass that could disagree with this one about who
+                     * is on it.
+                     */
+                    teamId: true,
+                },
+                consumePage: (rows) => {
+                    for (const row of rows) {
+                        addResponder(row.userId, ResponderSource.Team, row.teamId);
+                    }
+                },
+            });
+        }
+        // 3. Schedules attached to an escalation rule, expanded to their layer users.
+        const scheduleQuery = {
+            projectId: projectId,
+        };
+        if (onCallDutyPolicyId) {
+            scheduleQuery.onCallDutyPolicyId = onCallDutyPolicyId;
+        }
+        const escalationSchedules = [];
+        await this.readEveryPage({
+            description: "escalation rule schedules",
+            projectId: projectId,
+            completeness: completeness,
+            service: OnCallDutyPolicyEscalationRuleScheduleService,
+            query: scheduleQuery,
+            select: {
+                _id: true,
+                onCallDutyPolicyScheduleId: true,
+            },
+            consumePage: (rows) => {
+                escalationSchedules.push(...rows);
+            },
+        });
+        const scheduleIds = this.distinctIds(escalationSchedules.map((schedule) => {
+            return schedule.onCallDutyPolicyScheduleId;
+        }));
+        if (scheduleIds.length > 0) {
+            /*
+             * Going through the escalation-rule join even for the project-wide scope is
+             * deliberate: a schedule that is not attached to any policy pages nobody, and
+             * listing its members as unready responders would be noise an admin cannot act on.
+             */
+            await this.readEveryPage({
+                description: "schedule layer users",
+                projectId: projectId,
+                completeness: completeness,
+                service: OnCallDutyPolicyScheduleLayerUserService,
+                query: {
+                    projectId: projectId,
+                    onCallDutyPolicyScheduleId: new Includes(scheduleIds),
+                },
+                select: {
+                    _id: true,
+                    userId: true,
+                },
+                consumePage: (rows) => {
+                    for (const row of rows) {
+                        addResponder(row.userId, ResponderSource.Schedule);
+                    }
+                },
+            });
+        }
+        // 4. Users that overrides route pages to.
+        const overrideQuery = {
+            projectId: projectId,
+            /*
+             * An override that has already ended routes nothing, so it is not a reason anyone
+             * is a responder. Future overrides ARE included: the substitute needs to be
+             * reachable before their window opens, not discovered to be unreachable during it.
+             */
+            endsAt: QueryHelper.greaterThanEqualTo(OneUptimeDate.getCurrentDate()),
+        };
+        if (onCallDutyPolicyId) {
+            /*
+             * equalToOrNull, matching getRouteAlertToUserId exactly: an override with a NULL
+             * policy id is a GLOBAL override and applies to this policy too. Filtering on
+             * equality alone would drop every global override, which is the single most
+             * commonly configured kind.
+             */
+            overrideQuery.onCallDutyPolicyId =
+                QueryHelper.equalToOrNull(onCallDutyPolicyId);
+        }
+        await this.readEveryPage({
+            description: "on-call user overrides",
+            projectId: projectId,
+            completeness: completeness,
+            service: OnCallDutyPolicyUserOverrideService,
+            query: overrideQuery,
+            select: {
+                _id: true,
+                routeAlertsToUserId: true,
+            },
+            consumePage: (rows) => {
+                for (const row of rows) {
+                    addResponder(row.routeAlertsToUserId, ResponderSource.Override);
+                }
+            },
+        });
+        return responders;
+    }
+    /**
+     * The same four sources as resolveResponders, but asked the other way round: not "who
+     * does this project page" but "how, if at all, does this project page THESE people".
+     *
+     * The difference is the entire fix for the amplified N+1. Answering `reachedVia` for a
+     * forty-member team by resolving the whole project's responder set means reading every
+     * escalation rule, every team's full membership and every schedule's full layer roster
+     * — work proportional to the project, repeated per caller, to produce four booleans per
+     * user. Every read here is keyed on the userIds actually asked about instead, and the
+     * two that cannot be (which teams and which schedules are attached to a policy) are
+     * keyed on just those users' teams and schedules.
+     *
+     * Users with no source at all stay in the map with an empty set, because a user who is
+     * on no policy yet is exactly who the add-responder modal is asking about.
+     */
+    static async resolveRespondersForUsers(data) {
+        const responders = new Map();
+        for (const userId of data.userIds) {
+            responders.set(userId.toString(), {
+                sources: new Set(),
+                teamIds: new Set(),
+            });
+        }
+        const addSource = (userId, source, teamId) => {
+            if (!userId) {
+                return;
+            }
+            /*
+             * A row for somebody we were not asked about is dropped rather than added. The
+             * reads are all filtered on the user set already; this is the guard that keeps a
+             * future unfiltered read from silently widening the answer.
+             */
+            const attachment = responders.get(userId.toString());
+            if (!attachment) {
+                return;
+            }
+            attachment.sources.add(source);
+            if (teamId) {
+                attachment.teamIds.add(teamId.toString());
+            }
+        };
+        // 1. Attached directly to an escalation rule.
+        await this.readEveryPage({
+            description: "escalation rule users for a user set",
+            projectId: data.projectId,
+            completeness: data.completeness,
+            service: OnCallDutyPolicyEscalationRuleUserService,
+            query: {
+                projectId: data.projectId,
+                userId: new Includes(data.userIds),
+            },
+            select: {
+                _id: true,
+                userId: true,
+            },
+            consumePage: (rows) => {
+                for (const row of rows) {
+                    addSource(row.userId, ResponderSource.Direct);
+                }
+            },
+        });
+        // 2. In a team that is attached to an escalation rule.
+        const memberTeamIds = this.distinctIds(Array.from(data.teamIdsByUserId.values()).flat());
+        const attachedTeamIds = new Set();
+        if (memberTeamIds.length > 0) {
+            await this.readEveryPage({
+                description: "escalation rule teams for a user set",
+                projectId: data.projectId,
+                completeness: data.completeness,
+                service: OnCallDutyPolicyEscalationRuleTeamService,
+                query: {
+                    projectId: data.projectId,
+                    teamId: new Includes(memberTeamIds),
+                },
+                select: {
+                    _id: true,
+                    teamId: true,
+                },
+                consumePage: (rows) => {
+                    for (const row of rows) {
+                        if (row.teamId) {
+                            attachedTeamIds.add(row.teamId.toString());
+                        }
+                    }
+                },
+            });
+        }
+        if (attachedTeamIds.size > 0) {
+            for (const userId of data.userIds) {
+                const teamIds = data.teamIdsByUserId.get(userId.toString()) || [];
+                /*
+                 * Every matching team, not the first one and not a boolean. A user on two
+                 * attached teams is paged by both, so both belong on the row and both have to
+                 * match a team filter — the boolean this replaced could only ever have said
+                 * "some team", which is precisely the answer that made the team filter
+                 * impossible to build.
+                 */
+                for (const teamId of teamIds) {
+                    if (attachedTeamIds.has(teamId.toString())) {
+                        addSource(userId, ResponderSource.Team, teamId);
+                    }
+                }
+            }
+        }
+        // 3. On a layer of a schedule that is attached to an escalation rule.
+        const scheduleIdsByUserId = new Map();
+        await this.readEveryPage({
+            description: "schedule layer users for a user set",
+            projectId: data.projectId,
+            completeness: data.completeness,
+            service: OnCallDutyPolicyScheduleLayerUserService,
+            query: {
+                projectId: data.projectId,
+                userId: new Includes(data.userIds),
+            },
+            select: {
+                _id: true,
+                userId: true,
+                onCallDutyPolicyScheduleId: true,
+            },
+            consumePage: (rows) => {
+                for (const row of rows) {
+                    if (!row.userId || !row.onCallDutyPolicyScheduleId) {
+                        continue;
+                    }
+                    const key = row.userId.toString();
+                    const existing = scheduleIdsByUserId.get(key);
+                    if (existing) {
+                        existing.push(row.onCallDutyPolicyScheduleId);
+                        continue;
+                    }
+                    scheduleIdsByUserId.set(key, [row.onCallDutyPolicyScheduleId]);
+                }
+            },
+        });
+        const memberScheduleIds = this.distinctIds(Array.from(scheduleIdsByUserId.values()).flat());
+        const attachedScheduleIds = new Set();
+        if (memberScheduleIds.length > 0) {
+            await this.readEveryPage({
+                description: "escalation rule schedules for a user set",
+                projectId: data.projectId,
+                completeness: data.completeness,
+                service: OnCallDutyPolicyEscalationRuleScheduleService,
+                query: {
+                    projectId: data.projectId,
+                    onCallDutyPolicyScheduleId: new Includes(memberScheduleIds),
+                },
+                select: {
+                    _id: true,
+                    onCallDutyPolicyScheduleId: true,
+                },
+                consumePage: (rows) => {
+                    for (const row of rows) {
+                        if (row.onCallDutyPolicyScheduleId) {
+                            attachedScheduleIds.add(row.onCallDutyPolicyScheduleId.toString());
+                        }
+                    }
+                },
+            });
+        }
+        if (attachedScheduleIds.size > 0) {
+            for (const userId of data.userIds) {
+                const scheduleIds = scheduleIdsByUserId.get(userId.toString()) || [];
+                const isOnAnAttachedSchedule = scheduleIds.some((scheduleId) => {
+                    return attachedScheduleIds.has(scheduleId.toString());
+                });
+                if (isOnAnAttachedSchedule) {
+                    addSource(userId, ResponderSource.Schedule);
+                }
+            }
+        }
+        // 4. Substituted in by an override that has not ended.
+        await this.readEveryPage({
+            description: "on-call user overrides for a user set",
+            projectId: data.projectId,
+            completeness: data.completeness,
+            service: OnCallDutyPolicyUserOverrideService,
+            query: {
+                projectId: data.projectId,
+                routeAlertsToUserId: new Includes(data.userIds),
+                endsAt: QueryHelper.greaterThanEqualTo(OneUptimeDate.getCurrentDate()),
+            },
+            select: {
+                _id: true,
+                routeAlertsToUserId: true,
+            },
+            consumePage: (rows) => {
+                for (const row of rows) {
+                    addSource(row.routeAlertsToUserId, ResponderSource.Override);
+                }
+            },
+        });
+        return responders;
+    }
+    /**
+     * Which teams each of these users belongs to in this project — and, by existing at
+     * all, whether they belong to the project.
+     *
+     * One read doing both jobs is not a trick: team membership IS what "in this project"
+     * means for a User, which is a global model. Reading the teamIds at the same time is
+     * free and is what lets the Team responder source be resolved without expanding every
+     * team in the project into its full membership.
+     */
+    static async loadProjectMembership(projectId, userIds, completeness) {
+        const teamIdsByUserId = new Map();
+        await this.readEveryPage({
+            description: "project membership for a user set",
+            projectId: projectId,
+            completeness: completeness,
+            service: TeamMemberService,
+            query: {
+                projectId: projectId,
+                userId: new Includes(userIds),
+            },
+            select: {
+                _id: true,
+                userId: true,
+                teamId: true,
+            },
+            consumePage: (rows) => {
+                for (const row of rows) {
+                    if (!row.userId) {
+                        continue;
+                    }
+                    const key = row.userId.toString();
+                    const existing = teamIdsByUserId.get(key);
+                    if (existing) {
+                        if (row.teamId) {
+                            existing.push(row.teamId);
+                        }
+                        continue;
+                    }
+                    teamIdsByUserId.set(key, row.teamId ? [row.teamId] : []);
+                }
+            },
+        });
+        return teamIdsByUserId;
+    }
+    /**
+     * Turn a resolved responder set into per-user readiness. Every read here is batched
+     * over the whole set; the number of queries does not grow with the number of users or
+     * the number of severities.
+     */
+    static async buildReadiness(data) {
+        var _a;
+        const userIds = Array.from(data.responders.keys()).map((userId) => {
+            return new ObjectID(userId);
+        });
+        if (userIds.length === 0) {
+            return [];
+        }
+        const inputs = await this.loadInputs({
+            projectId: data.projectId,
+            userIds: userIds,
+            projectSettings: data.projectSettings,
+            completeness: data.completeness,
+        });
+        /*
+         * ONE read for every team named anywhere in the responder set, rather than one per
+         * responder. A team on an escalation rule is shared by every one of its members, so
+         * the per-member read would be the same N+1 that made the report this service
+         * replaced unusable — see readEveryPage.
+         */
+        const teamNamesById = await this.loadTeamNames({
+            projectId: data.projectId,
+            teamIds: this.distinctIds(Array.from(data.responders.values())
+                .flatMap((attachment) => {
+                return Array.from(attachment.teamIds);
+            })
+                .map((teamId) => {
+                return new ObjectID(teamId);
+            })),
+            completeness: data.completeness,
+        });
+        const readiness = [];
+        for (const user of inputs.users) {
+            const userIdString = ((_a = user.id) === null || _a === void 0 ? void 0 : _a.toString()) || "";
+            const attachment = data.responders.get(userIdString) || {
+                sources: new Set(),
+                teamIds: new Set(),
+            };
+            readiness.push(this.buildUserReadiness(user, attachment, userIdString, inputs, teamNamesById));
+        }
+        return this.sortReadiness(readiness);
+    }
+    /**
+     * Team id -> team name, for every team that pages somebody in the responder set.
+     *
+     * A team whose row did not come back is simply absent from the map, and
+     * buildUserReadiness then drops it from the responder's `teams` rather than rendering an
+     * id or an empty chip. That is the right direction to fail in for a filter: an option
+     * that cannot be labelled is an option nobody can choose deliberately, whereas a chip
+     * reading a bare uuid is one an admin might act on.
+     */
+    static async loadTeamNames(data) {
+        const teamNamesById = new Map();
+        if (data.teamIds.length === 0) {
+            return teamNamesById;
+        }
+        await this.readEveryPage({
+            description: "teams that page a responder",
+            projectId: data.projectId,
+            completeness: data.completeness,
+            service: TeamService,
+            query: {
+                projectId: data.projectId,
+                _id: new Includes(data.teamIds),
+            },
+            select: {
+                _id: true,
+                name: true,
+            },
+            consumePage: (rows) => {
+                for (const row of rows) {
+                    if (row.id && row.name) {
+                        teamNamesById.set(row.id.toString(), row.name);
+                    }
+                }
+            },
+        });
+        return teamNamesById;
+    }
+    static sortReadiness(readiness) {
+        readiness.sort((a, b) => {
+            const rankDifference = STATUS_SORT_RANK[a.status] - STATUS_SORT_RANK[b.status];
+            if (rankDifference !== 0) {
+                return rankDifference;
+            }
+            return a.userName.localeCompare(b.userName);
+        });
+        return readiness;
+    }
+    /*
+     * Read the project's switches once. They are what decides whether "no rule for Sev4"
+     * means "falls back to email" or "is dropped on the floor", and whether a verified SMS
+     * number is a way to reach somebody or a decoration. A readiness surface that cannot
+     * tell those apart is not diagnosing anything.
+     */
+    static async loadProjectSettings(projectId) {
+        const project = await ProjectService.findOneById({
+            id: projectId,
+            select: {
+                _id: true,
+                disableOnCallNotificationFallback: true,
+                enableSmsNotifications: true,
+                enableCallNotifications: true,
+                enableWhatsAppNotifications: true,
+                enableTelegramNotifications: true,
+            },
+            props: {
+                isRoot: true,
+            },
+        });
+        /*
+         * A missing project row reads as every paid channel OFF and the fallback ON, which
+         * is the pairing that produces the loudest answer rather than the most convenient
+         * one. Defaulting a switch to "on" would let a project we could not read certify
+         * responders as reachable on channels that may be switched off.
+         */
+        return {
+            isFallbackDisabled: Boolean(project === null || project === void 0 ? void 0 : project.disableOnCallNotificationFallback),
+            enableSmsNotifications: Boolean(project === null || project === void 0 ? void 0 : project.enableSmsNotifications),
+            enableCallNotifications: Boolean(project === null || project === void 0 ? void 0 : project.enableCallNotifications),
+            enableWhatsAppNotifications: Boolean(project === null || project === void 0 ? void 0 : project.enableWhatsAppNotifications),
+            enableTelegramNotifications: Boolean(project === null || project === void 0 ? void 0 : project.enableTelegramNotifications),
+        };
+    }
+    static async loadInputs(data) {
+        const users = [];
+        await this.readEveryPage({
+            description: "responder user records",
+            projectId: data.projectId,
+            completeness: data.completeness,
+            service: UserService,
+            query: {
+                _id: new Includes(data.userIds),
+            },
+            select: {
+                _id: true,
+                name: true,
+                email: true,
+                profilePictureId: true,
+            },
+            consumePage: (rows) => {
+                users.push(...rows);
+            },
+        });
+        const methodsByUserId = await this.loadMethods(data.projectId, data.userIds, data.completeness);
+        const coverageByKey = await this.loadCoverageIndex(data.projectId, data.userIds, data.completeness);
+        const incidentSeverityModels = [];
+        await this.readEveryPage({
+            description: "incident severities",
+            projectId: data.projectId,
+            completeness: data.completeness,
+            service: IncidentSeverityService,
+            query: {
+                projectId: data.projectId,
+            },
+            select: {
+                _id: true,
+                name: true,
+            },
+            sort: {
+                order: SortOrder.Ascending,
+            },
+            consumePage: (rows) => {
+                incidentSeverityModels.push(...rows);
+            },
+        });
+        const alertSeverityModels = [];
+        await this.readEveryPage({
+            description: "alert severities",
+            projectId: data.projectId,
+            completeness: data.completeness,
+            service: AlertSeverityService,
+            query: {
+                projectId: data.projectId,
+            },
+            select: {
+                _id: true,
+                name: true,
+            },
+            sort: {
+                order: SortOrder.Ascending,
+            },
+            consumePage: (rows) => {
+                alertSeverityModels.push(...rows);
+            },
+        });
+        return {
+            users: users,
+            methodsByUserId: methodsByUserId,
+            coverageByKey: coverageByKey,
+            incidentSeverities: this.toSeverityRefs(incidentSeverityModels),
+            alertSeverities: this.toSeverityRefs(alertSeverityModels),
+            projectSettings: data.projectSettings,
+        };
+    }
+    /**
+     * One paged read per method model, each over the whole responder set.
+     *
+     * All SEVEN channels are here. TeamComplianceService looked at four and therefore told
+     * a responder whose only method was Telegram, WhatsApp or Webhook that they were
+     * non-compliant while the runtime was quite happily paging them — a false alarm that
+     * teaches admins to ignore the table, which is worse than the table not existing.
+     */
+    static async loadMethods(projectId, userIds, completeness) {
+        const methodsByUserId = new Map();
+        const addMethod = (row, method) => {
+            const methodId = row.id;
+            /*
+             * A row with no owner, or no id of its own, is dropped. Neither is reachable while
+             * every select below asks for `_id` and every method row is owned — a primary key
+             * is not optional in the database — so this is a guard against a future select
+             * being trimmed rather than a case that happens.
+             *
+             * It is a drop rather than a partial emit because the alternatives are both worse.
+             * Emitting the method without an id would mean typing methodId as optional, which
+             * pushes this impossible case out to every caller and gives the rule form an option
+             * it cannot submit. Dropping errs towards reporting the responder as LESS reachable
+             * than they are, which is the direction this service always errs in: a false amber
+             * gets investigated, and a false green does not.
+             */
+            if (!row.userId || !methodId) {
+                return;
+            }
+            const readinessMethod = Object.assign({ methodId: methodId }, method);
+            const key = row.userId.toString();
+            const existing = methodsByUserId.get(key);
+            if (existing) {
+                existing.push(readinessMethod);
+                return;
+            }
+            methodsByUserId.set(key, [readinessMethod]);
+        };
+        await this.readEveryPage({
+            description: "push notification methods",
+            projectId: projectId,
+            completeness: completeness,
+            service: UserPushService,
+            query: {
+                projectId: projectId,
+                userId: new Includes(userIds),
+            },
+            select: {
+                _id: true,
+                userId: true,
+                deviceName: true,
+                isVerified: true,
+            },
+            consumePage: (rows) => {
+                for (const row of rows) {
+                    addMethod(row, {
+                        methodType: ReadinessMethodType.Push,
+                        maskedIdentifier: maskIdentifier(row.deviceName, MaskedIdentifierKind.Handle),
+                        isVerified: Boolean(row.isVerified),
+                    });
+                }
+            },
+        });
+        await this.readEveryPage({
+            description: "email notification methods",
+            projectId: projectId,
+            completeness: completeness,
+            service: UserEmailService,
+            query: {
+                projectId: projectId,
+                userId: new Includes(userIds),
+            },
+            select: {
+                _id: true,
+                userId: true,
+                email: true,
+                isVerified: true,
+            },
+            consumePage: (rows) => {
+                var _a;
+                for (const row of rows) {
+                    addMethod(row, {
+                        methodType: ReadinessMethodType.Email,
+                        maskedIdentifier: maskIdentifier((_a = row.email) === null || _a === void 0 ? void 0 : _a.toString(), MaskedIdentifierKind.Email),
+                        isVerified: Boolean(row.isVerified),
+                    });
+                }
+            },
+        });
+        await this.readEveryPage({
+            description: "SMS notification methods",
+            projectId: projectId,
+            completeness: completeness,
+            service: UserSmsService,
+            query: {
+                projectId: projectId,
+                userId: new Includes(userIds),
+            },
+            select: {
+                _id: true,
+                userId: true,
+                phone: true,
+                isVerified: true,
+            },
+            consumePage: (rows) => {
+                var _a;
+                for (const row of rows) {
+                    addMethod(row, {
+                        methodType: ReadinessMethodType.SMS,
+                        maskedIdentifier: maskIdentifier((_a = row.phone) === null || _a === void 0 ? void 0 : _a.toString(), MaskedIdentifierKind.Phone),
+                        isVerified: Boolean(row.isVerified),
+                    });
+                }
+            },
+        });
+        await this.readEveryPage({
+            description: "call notification methods",
+            projectId: projectId,
+            completeness: completeness,
+            service: UserCallService,
+            query: {
+                projectId: projectId,
+                userId: new Includes(userIds),
+            },
+            select: {
+                _id: true,
+                userId: true,
+                phone: true,
+                isVerified: true,
+            },
+            consumePage: (rows) => {
+                var _a;
+                for (const row of rows) {
+                    addMethod(row, {
+                        methodType: ReadinessMethodType.Call,
+                        maskedIdentifier: maskIdentifier((_a = row.phone) === null || _a === void 0 ? void 0 : _a.toString(), MaskedIdentifierKind.Phone),
+                        isVerified: Boolean(row.isVerified),
+                    });
+                }
+            },
+        });
+        await this.readEveryPage({
+            description: "WhatsApp notification methods",
+            projectId: projectId,
+            completeness: completeness,
+            service: UserWhatsAppService,
+            query: {
+                projectId: projectId,
+                userId: new Includes(userIds),
+            },
+            select: {
+                _id: true,
+                userId: true,
+                phone: true,
+                isVerified: true,
+            },
+            consumePage: (rows) => {
+                var _a;
+                for (const row of rows) {
+                    addMethod(row, {
+                        methodType: ReadinessMethodType.WhatsApp,
+                        maskedIdentifier: maskIdentifier((_a = row.phone) === null || _a === void 0 ? void 0 : _a.toString(), MaskedIdentifierKind.Phone),
+                        isVerified: Boolean(row.isVerified),
+                    });
+                }
+            },
+        });
+        await this.readEveryPage({
+            description: "Telegram notification methods",
+            projectId: projectId,
+            completeness: completeness,
+            service: UserTelegramService,
+            query: {
+                projectId: projectId,
+                userId: new Includes(userIds),
+            },
+            /*
+             * The handle only — never telegramChatId. The chat id is the addressable target a
+             * bot sends to; the handle is the human-facing label, and it is the one a user can
+             * recognise as theirs.
+             */
+            select: {
+                _id: true,
+                userId: true,
+                telegramUserHandle: true,
+                isVerified: true,
+            },
+            consumePage: (rows) => {
+                for (const row of rows) {
+                    addMethod(row, {
+                        methodType: ReadinessMethodType.Telegram,
+                        maskedIdentifier: maskIdentifier(row.telegramUserHandle, MaskedIdentifierKind.Handle),
+                        isVerified: Boolean(row.isVerified),
+                    });
+                }
+            },
+        });
+        await this.readEveryPage({
+            description: "webhook notification methods",
+            projectId: projectId,
+            completeness: completeness,
+            service: UserWebhookService,
+            query: {
+                projectId: projectId,
+                userId: new Includes(userIds),
+            },
+            /*
+             * `name` ONLY. UserWebhook.webhookUrl is a bearer credential — anyone holding a
+             * Slack/Discord/Teams hook URL can post as the integration — so it is never
+             * selected here and never leaves the server on this path.
+             * Common/UI/Utils/NotificationMethodUtil.ts documents the same rule for the rule
+             * tables and reads only `name`; this follows it. The masked name is enough to
+             * answer the only question readiness asks, which is whether a webhook exists.
+             */
+            select: {
+                _id: true,
+                userId: true,
+                name: true,
+            },
+            consumePage: (rows) => {
+                for (const row of rows) {
+                    /*
+                     * isVerified: true, with no isVerified column behind it. UserWebhook has no
+                     * verification concept at all — its presence IS the whole test, which is
+                     * exactly how the runtime fallback treats it. Reporting it as unverified would
+                     * paint the one channel that is guaranteed to work as the one channel that
+                     * will not.
+                     */
+                    addMethod(row, {
+                        methodType: ReadinessMethodType.Webhook,
+                        maskedIdentifier: maskIdentifier(row.name, MaskedIdentifierKind.Handle),
+                        isVerified: true,
+                    });
+                }
+            },
+        });
+        for (const methods of methodsByUserId.values()) {
+            methods.sort((a, b) => {
+                return (METHOD_DISPLAY_ORDER.indexOf(a.methodType) -
+                    METHOD_DISPLAY_ORDER.indexOf(b.methodType));
+            });
+        }
+        return methodsByUserId;
+    }
+    /**
+     * ONE paged read over UserNotificationRule for the whole responder set, folded into a
+     * map keyed by (userId, ruleType, severityId).
+     *
+     * The folding happens per page rather than after the read for a reason that is not
+     * about tidiness: this is by far the largest table this service touches — users x rule
+     * types x severities x methods — so a project of a few thousand responders holds
+     * hundreds of thousands of rows here, all of which collapse into at most a few cells
+     * per user. Accumulating them first and folding second would hold the whole table in
+     * memory to produce a map a thousand times smaller.
+     *
+     * Opt-out rows are read alongside real rules rather than filtered out in SQL, because
+     * both halves are needed: a cell with an opt-out is Ready (deliberate silence) while a
+     * cell with nothing at all is PartiallyReady (silence nobody chose), and telling those
+     * apart is the entire reason the isOptOut column exists.
+     *
+     * The in-memory split is `isOptOut === true`, which is the exact dual of the
+     * notOptOutRuleQuery predicate the paging path uses — deliberately NOT `isOptOut ===
+     * false`. The column is nullable and was added long after these rows started existing,
+     * so it is NULL on every rule in every existing install. Testing for false would
+     * classify all of them as neither rules nor opt-outs, and this service would report a
+     * fully-configured project as entirely unready.
+     */
+    static async loadCoverageIndex(projectId, userIds, completeness) {
+        const coverageByKey = new Map();
+        await this.readEveryPage({
+            description: "user notification rules",
+            projectId: projectId,
+            completeness: completeness,
+            service: UserNotificationRuleService,
+            query: {
+                projectId: projectId,
+                userId: new Includes(userIds),
+            },
+            select: {
+                _id: true,
+                userId: true,
+                ruleType: true,
+                incidentSeverityId: true,
+                alertSeverityId: true,
+                isOptOut: true,
+            },
+            consumePage: (rows) => {
+                for (const rule of rows) {
+                    this.foldRuleIntoCoverage(rule, coverageByKey);
+                }
+            },
+        });
+        return coverageByKey;
+    }
+    static foldRuleIntoCoverage(rule, coverageByKey) {
+        var _a;
+        const scope = RULE_TYPE_SCOPES.find((candidate) => {
+            return candidate.ruleType === rule.ruleType;
+        });
+        /*
+         * Not one of the four paging rule types — a handoff rule, or something added later.
+         * It covers no page, so it covers no cell. This is defect 4 of
+         * TeamComplianceService, which matched on severity alone and let a
+         * WHEN_USER_GOES_OFF_CALL rule certify incident coverage.
+         */
+        if (!scope) {
+            return;
+        }
+        /*
+         * Take the severity from the column the RULE TYPE dictates, never from whichever one
+         * happens to be populated. An alert rule carrying a stray incidentSeverityId matches
+         * no page at runtime, so it must not be allowed to satisfy a cell here.
+         */
+        const severityId = scope.severityKind === SeverityKind.Incident
+            ? rule.incidentSeverityId
+            : rule.alertSeverityId;
+        /*
+         * A severity-scoped rule with a NULL severity is the Gap G corpse: the paging path
+         * counts episode rules filtered by a concrete severity id, so NULL matches nothing
+         * and the rule is unreachable. Counting it as coverage would report exactly the
+         * users worst affected by that bug as fully ready.
+         */
+        if (!severityId) {
+            return;
+        }
+        const key = buildCoverageKey(((_a = rule.userId) === null || _a === void 0 ? void 0 : _a.toString()) || "", scope.ruleType, severityId.toString());
+        const state = coverageByKey.get(key) || {
+            hasRule: false,
+            isOptOut: false,
+        };
+        if (rule.isOptOut === true) {
+            state.isOptOut = true;
+        }
+        else {
+            state.hasRule = true;
+        }
+        coverageByKey.set(key, state);
+    }
+    static buildUserReadiness(user, attachment, userIdString, inputs, teamNamesById) {
+        var _a, _b, _c;
+        const sources = attachment.sources;
+        const methods = inputs.methodsByUserId.get(userIdString) || [];
+        const coverage = [];
+        for (const scope of RULE_TYPE_SCOPES) {
+            const severities = scope.severityKind === SeverityKind.Incident
+                ? inputs.incidentSeverities
+                : inputs.alertSeverities;
+            for (const severity of severities) {
+                const state = inputs.coverageByKey.get(buildCoverageKey(userIdString, scope.ruleType, severity.id.toString()));
+                coverage.push({
+                    ruleType: scope.ruleType,
+                    severityId: severity.id,
+                    severityName: severity.name,
+                    hasRule: Boolean(state === null || state === void 0 ? void 0 : state.hasRule),
+                    isOptOut: Boolean(state === null || state === void 0 ? void 0 : state.isOptOut),
+                });
+            }
+        }
+        /*
+         * Verified is necessary and not sufficient — webhooks are reported verified by
+         * construction above, so this one predicate covers the "webhook counts without
+         * verification" rule without a special case leaking into the status logic.
+         */
+        const verifiedMethods = methods.filter((method) => {
+            return method.isVerified;
+        });
+        /*
+         * USABLE is verified AND on a channel the project has switched on. Status used to be
+         * computed from verification alone, which meant a responder whose only verified
+         * methods were SMS and Call, in a project with SMS and Call switched off, rendered
+         * Ready and green while being completely unpageable — the exact false green this
+         * service exists to make impossible. The project switches are already loaded, sit
+         * two fields away, and the runtime consults them on every send, so ignoring them here
+         * was never a judgement call.
+         */
+        const usableMethods = verifiedMethods.filter((method) => {
+            return this.isChannelEnabled(method.methodType, inputs.projectSettings);
+        });
+        const disabledChannels = this.distinctStrings(verifiedMethods
+            .filter((method) => {
+            return !this.isChannelEnabled(method.methodType, inputs.projectSettings);
+        })
+            .map((method) => {
+            return method.methodType;
+        }));
+        const uncoveredCells = coverage.filter((cell) => {
+            return !cell.hasRule && !cell.isOptOut;
+        });
+        let status = ReadinessStatus.Ready;
+        if (usableMethods.length === 0) {
+            status = ReadinessStatus.NotReachable;
+        }
+        else if (uncoveredCells.length > 0) {
+            status = ReadinessStatus.PartiallyReady;
+        }
+        const reasons = this.buildReasons({
+            status: status,
+            methods: methods,
+            verifiedMethods: verifiedMethods,
+            usableMethods: usableMethods,
+            disabledChannels: disabledChannels,
+            uncoveredCells: uncoveredCells,
+            projectSettings: inputs.projectSettings,
+        });
+        return {
+            userId: user.id,
+            userName: ((_a = user.name) === null || _a === void 0 ? void 0 : _a.toString()) || ((_b = user.email) === null || _b === void 0 ? void 0 : _b.toString()) || "Unknown User",
+            userEmail: ((_c = user.email) === null || _c === void 0 ? void 0 : _c.toString()) || "",
+            userProfilePictureId: user.profilePictureId,
+            status: status,
+            methods: methods,
+            coverage: coverage,
+            reasons: reasons,
+            reachedVia: RESPONDER_SOURCE_ORDER.filter((source) => {
+                return sources.has(source);
+            }),
+            /*
+             * A fresh array per user, never a shared one. InMemoryTTLCache stores by reference
+             * and hands the same object graph to every caller inside its TTL, so a list shared
+             * between two responders would let a mutation anywhere downstream rewrite the
+             * cached answer for both.
+             *
+             * Sorted by name so the column and the filter chip read the same way for every
+             * responder, and so the order does not depend on which membership row the database
+             * happened to return first.
+             */
+            teams: Array.from(attachment.teamIds)
+                .map((teamId) => {
+                const name = teamNamesById.get(teamId);
+                return name ? { _id: new ObjectID(teamId), name: name } : null;
+            })
+                .filter((team) => {
+                return team !== null;
+            })
+                .sort((a, b) => {
+                return a.name.localeCompare(b.name);
+            }),
+        };
+    }
+    /**
+     * Whether this project can send on this channel at all.
+     *
+     * Push, Email and Webhook have no project switch: the first two are zero-cost and the
+     * third is somebody else's endpoint, so nothing gates them and they are always
+     * available. The four paid channels do, and the runtime honours them — SmsService and
+     * CallService refuse at send time, and the fallback checks all four before it picks a
+     * channel to spend money on. Treating all four alike here is the conservative reading:
+     * a responder marked unreachable because their project switched their only channel off
+     * is an alarm somebody can act on, while the reverse mistake is a page nobody hears.
+     */
+    static isChannelEnabled(methodType, settings) {
+        if (methodType === ReadinessMethodType.SMS) {
+            return settings.enableSmsNotifications;
+        }
+        if (methodType === ReadinessMethodType.Call) {
+            return settings.enableCallNotifications;
+        }
+        if (methodType === ReadinessMethodType.WhatsApp) {
+            return settings.enableWhatsAppNotifications;
+        }
+        if (methodType === ReadinessMethodType.Telegram) {
+            return settings.enableTelegramNotifications;
+        }
+        return true;
+    }
+    /**
+     * Sentences an admin can act on, in the order they should act on them.
+     *
+     * Not status names, not rule-type enum values, not "non-compliant" — every line names
+     * a specific missing thing and what happens because of it. The consequence clause is
+     * the part that matters: "no rule for Sev4" is a shrug, "no rule for Sev4, pages are
+     * dropped" is a ticket.
+     */
+    static buildReasons(data) {
+        const reasons = [];
+        if (data.status === ReadinessStatus.NotReachable) {
+            /*
+             * Three ways to be unreachable, and they need three different sentences because
+             * they need three different people to fix them: the user adds a method, the user
+             * verifies a method, or an admin turns a channel back on. A single "cannot be
+             * paged" line sends all three to the wrong place.
+             */
+            if (data.verifiedMethods.length > 0) {
+                reasons.push("No usable notification method - cannot be paged");
+                reasons.push(`Every method they have verified is on ${data.disabledChannels.join(", ")}, and this project has ${data.disabledChannels.length === 1 ? "that channel" : "those channels"} switched off - that is a project setting, not something this user can fix`);
+                return reasons;
+            }
+            reasons.push("No verified notification method - cannot be paged");
+            /*
+             * "They have nothing" and "they have something they never verified" look identical
+             * in a status chip and could not be more different to fix: the second needs one
+             * click from the user, not a conversation about how on-call works.
+             */
+            if (data.methods.length > 0) {
+                const unverified = this.distinctStrings(data.methods.map((method) => {
+                    return method.methodType;
+                }));
+                reasons.push(`Added ${unverified.join(", ")} but never verified - unverified methods are never used`);
+            }
+            else {
+                reasons.push("Ask this user to add and verify a notification method in User Settings > Notification Methods");
+            }
+            /*
+             * Coverage is meaningless for someone nothing can reach. Listing their missing
+             * rules underneath would bury the one sentence that matters under a dozen that do
+             * not.
+             */
+            return reasons;
+        }
+        /*
+         * Note what is deliberately NOT said here. A responder who still has one working
+         * channel but also has, say, an SMS number the project has switched off is reachable,
+         * and saying so on their row would put a warning sentence on every single user in a
+         * project that has switched SMS off — a line nobody can act on, attached to people
+         * who have nothing wrong with them, which is how a readiness surface teaches admins
+         * to stop reading it. The stranded channel matters only when it is the reason nobody
+         * can be reached, and that case is handled above.
+         */
+        if (data.uncoveredCells.length === 0) {
+            return reasons;
+        }
+        const fallbackChannels = this.describeFallbackChannels(data.usableMethods, data.projectSettings);
+        /*
+         * One sentence per rule type, listing its missing severities, rather than one per
+         * cell. A project with four severities and no rules at all would otherwise produce
+         * sixteen near-identical lines that nobody reads to the end of.
+         */
+        for (const scope of RULE_TYPE_SCOPES) {
+            const severityNames = this.distinctStrings(data.uncoveredCells
+                .filter((cell) => {
+                return cell.ruleType === scope.ruleType;
+            })
+                .map((cell) => {
+                return cell.severityName || "this severity";
+            }));
+            if (severityNames.length === 0) {
+                continue;
+            }
+            const subject = `No rules for ${severityNames.join(", ")} ${scope.subjectNoun}`;
+            if (data.projectSettings.isFallbackDisabled) {
+                reasons.push(`${subject} - pages are dropped because on-call fallback is disabled for this project`);
+            }
+            else if (fallbackChannels.length === 0) {
+                /*
+                 * Not reachable from here today — a usable method always yields a fallback
+                 * channel — but kept so that a future channel with no fallback path degrades
+                 * into an honest sentence instead of "pages fall back to " with nothing after
+                 * it.
+                 */
+                reasons.push(`${subject} - pages cannot be delivered`);
+            }
+            else {
+                reasons.push(`${subject} - pages fall back to ${fallbackChannels.join(", ")}`);
+            }
+        }
+        return reasons;
+    }
+    /**
+     * The channels a fallback page would actually arrive on, so the reason sentences name
+     * the real thing rather than a hopeful "some verified method".
+     *
+     * This mirrors UserNotificationRuleService.chooseFallbackChannels exactly, including
+     * the project switches: zero-cost channels first and BOTH of them if present, then one
+     * paid channel in escalating-intrusiveness order, then webhook. If that function's
+     * order ever changes, this one has to change with it — a readiness surface promising
+     * "falls back to SMS" for a project that has SMS switched off is worse than saying
+     * nothing. The switch checks are redundant with the usable-method filter upstream and
+     * are kept anyway, because this function's whole value is being a line-by-line mirror
+     * of the one that does the real thing.
+     */
+    static describeFallbackChannels(usableMethods, settings) {
+        const has = (methodType) => {
+            return usableMethods.some((method) => {
+                return method.methodType === methodType;
+            });
+        };
+        const zeroCost = [];
+        if (has(ReadinessMethodType.Push)) {
+            zeroCost.push(ReadinessMethodType.Push);
+        }
+        if (has(ReadinessMethodType.Email)) {
+            zeroCost.push(ReadinessMethodType.Email);
+        }
+        if (zeroCost.length > 0) {
+            return zeroCost;
+        }
+        if (settings.enableSmsNotifications && has(ReadinessMethodType.SMS)) {
+            return [ReadinessMethodType.SMS];
+        }
+        if (settings.enableCallNotifications && has(ReadinessMethodType.Call)) {
+            return [ReadinessMethodType.Call];
+        }
+        if (settings.enableWhatsAppNotifications &&
+            has(ReadinessMethodType.WhatsApp)) {
+            return [ReadinessMethodType.WhatsApp];
+        }
+        if (settings.enableTelegramNotifications &&
+            has(ReadinessMethodType.Telegram)) {
+            return [ReadinessMethodType.Telegram];
+        }
+        if (has(ReadinessMethodType.Webhook)) {
+            return [ReadinessMethodType.Webhook];
+        }
+        return [];
+    }
+    static toSeverityRefs(severities) {
+        const refs = [];
+        for (const severity of severities) {
+            if (!severity.id) {
+                continue;
+            }
+            refs.push({
+                id: severity.id,
+                name: severity.name || "Unnamed Severity",
+            });
+        }
+        return refs;
+    }
+    static distinctIds(ids) {
+        const seen = new Set();
+        const distinct = [];
+        for (const id of ids) {
+            if (!id) {
+                continue;
+            }
+            const key = id.toString();
+            if (seen.has(key)) {
+                continue;
+            }
+            seen.add(key);
+            distinct.push(id);
+        }
+        return distinct;
+    }
+    static distinctStrings(values) {
+        const seen = new Set();
+        const distinct = [];
+        for (const value of values) {
+            if (seen.has(value)) {
+                continue;
+            }
+            seen.add(value);
+            distinct.push(value);
+        }
+        return distinct;
+    }
+}
+OnCallReadinessService.summaryCache = new InMemoryTTLCache(10000);
+OnCallReadinessService.userCache = new InMemoryTTLCache(10000);
+export default OnCallReadinessService;
+//# sourceMappingURL=OnCallReadinessService.js.map