@oneuptime/common 12.0.25 → 12.0.26

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

@@ -11,8 +11,126 @@ import DatabaseService from "./DatabaseService";
 import Model from "../../Models/DatabaseModels/NetworkDeviceDiscoveryScan";
 import CaptureSpan from "../Utils/Telemetry/CaptureSpan";
 import BadDataException from "../../Types/Exception/BadDataException";
+import OneUptimeDate from "../../Types/Date";
+import LIMIT_MAX from "../../Types/Database/LimitMax";
+import ProbeService from "./ProbeService";
+import RelationIdUtil from "../Utils/Database/RelationIdUtil";
 import ScanTargetUtil from "../../Utils/NetworkDiscovery/ScanTargetUtil";
 import ScanNameUtil from "../../Utils/NetworkDiscovery/ScanNameUtil";
+import SnmpScanConfigUtil from "../../Utils/NetworkDiscovery/SnmpScanConfigUtil";
+import { getNextScanAt } from "../../Utils/NetworkDiscovery/RescanIntervalUtil";
+import ScanModeUtil from "../../Utils/NetworkDiscovery/ScanModeUtil";
+/*
+ * The two spellings a many-to-one reference reaches a hook under: the
+ * dashboard posts the relation object, server callers write the FK column.
+ * See RelationIdUtil.
+ */
+const PROBE_RELATION_KEYS = ["probeId", "probe"];
+/*
+ * The columns that decide what the probe sweeps, and what it sweeps with.
+ * Changing any of them means the results already on the row describe a sweep
+ * that no longer exists — which is what onUpdateSuccess below acts on.
+ *
+ * `probe` is folded into `probeId` by RelationIdUtil rather than listed here,
+ * because the same reference arrives under either name.
+ */
+const SWEEP_COLUMNS = [
+    "cidr",
+    "probeId",
+    /*
+     * The method as well as the credentials: turning SNMP off (or back on)
+     * changes what the sweep asks of every address, so the hosts already on the
+     * row answered a different question (issue #3445).
+     */
+    "isSnmpEnabled",
+    /*
+     * The ordered credential list. Listed FIRST among the credential columns
+     * because it is the one the form actually posts now; the flattened columns
+     * below it are mirrored from its first entry (see applySnmpConfigs) and
+     * remain here so a scan edited through the API with only those fields still
+     * retires its run (issue #3458).
+     */
+    "snmpConfigs",
+    "snmpVersion",
+    "snmpCommunityString",
+    "snmpPort",
+    "snmpV3SecurityLevel",
+    "snmpV3Username",
+    "snmpV3AuthProtocol",
+    "snmpV3AuthKey",
+    "snmpV3PrivProtocol",
+    "snmpV3PrivKey",
+];
+/*
+ * The numeric columns a form can hand back as an empty string.
+ *
+ * A Number field posts its value as text (Common/UI/Components/Forms/Fields/
+ * FormField.tsx sets it straight from the input), so an operator who clears
+ * the box sends "" — and "" into an integer column is a Postgres error, i.e. a
+ * 500 where the operator simply meant "leave this unset". Clearing a box was
+ * hard to do before these fields were editable, because a create form starts
+ * them empty; an edit form starts them filled.
+ */
+const NULLABLE_NUMBER_COLUMNS = [
+    "snmpPort",
+    "rescanIntervalInMinutes",
+];
+/*
+ * The columns that decide WHEN the scan runs again, and nothing else. They
+ * never retire a result — they only re-derive nextScanAt.
+ */
+/*
+ * The single credential set a scan carried before `snmpConfigs` existed. Still
+ * written — mirrored from the list's first entry — so a probe that predates
+ * the list keeps sweeping with real credentials; see applySnmpConfigs.
+ */
+const LEGACY_SNMP_COLUMNS = [
+    "snmpVersion",
+    "snmpCommunityString",
+    "snmpPort",
+    "snmpV3SecurityLevel",
+    "snmpV3Username",
+    "snmpV3AuthProtocol",
+    "snmpV3AuthKey",
+    "snmpV3PrivProtocol",
+    "snmpV3PrivKey",
+];
+const SCHEDULE_COLUMNS = [
+    "isRecurring",
+    "rescanIntervalInMinutes",
+];
+/*
+ * Everything a finished run left on the row. Written together, as one
+ * statement, to put the scan back in the state a brand-new one is created in:
+ * queued, with nothing to show yet.
+ *
+ * This is the same reset the requeue worker performs on a recurring scan that
+ * is due (Workers/Jobs/NetworkDeviceDiscovery/RequeueRecurringScans.ts) with
+ * one deliberate difference: the results ARE cleared here. The worker keeps
+ * them because a recurring scan re-runs the SAME sweep, so last run's
+ * inventory is still the best answer available until the next one lands. A
+ * scan whose target or credentials just changed has no such excuse — its
+ * hosts came from somewhere the scan no longer points at.
+ */
+const RETIRE_RUN_PAYLOAD = {
+    status: "Pending",
+    /*
+     * Not cleared but replaced, because the row has some explaining to do: the
+     * operator saved a settings change and the scan's results vanished. The
+     * scans list renders this sentence in the results cell of a scan that has
+     * not reported (Dashboard Components/NetworkDevice/DiscoveryScanOutcome),
+     * which is exactly where the missing results used to be. The claim endpoint
+     * clears it the moment a probe picks the scan up.
+     */
+    statusMessage: "Settings changed, so this scan is queued to run again. The hosts the previous run found have been cleared - they described settings this scan no longer has.",
+    startedAt: null,
+    completedAt: null,
+    nextScanAt: null,
+    discoveredDevices: null,
+    scannedHostCount: null,
+    respondedHostCount: null,
+    autoImportProcessedAt: null,
+};
 export class Service extends DatabaseService {
     constructor() {
         super(Model);
@@ -52,18 +170,102 @@ export class Service extends DatabaseService {
          */
         createBy.data["name"] =
             (_a = ScanNameUtil.normalize(createBy.data.name)) !== null && _a !== void 0 ? _a : undefined;
+        this.nullEmptyNumbers(createBy.data, Object.keys(createBy.data || {}));
+        const createData = createBy.data;
+        /*
+         * The keys the CLIENT actually supplied, not the keys the object has.
+         *
+         * `createBy.data` is a model INSTANCE, and every column on it is declared
+         * as a class field with `= undefined` — so `Object.keys()` returns all 37
+         * column names on a brand-new scan no matter what was posted. Handing that
+         * to applySnmpConfigs made its "the payload wins where it speaks for
+         * itself" guard fire for all nine flattened columns, every time, and the
+         * mirror it protects became a permanent no-op on this path: a scan created
+         * through the wizard (which posts `snmpConfigs` and nothing else) stored
+         * its credentials in the list while its flattened columns kept the bare
+         * Postgres defaults, and every probe a version behind swept it with
+         * v2c/"public"/161 and reported the confident zero the mirror exists to
+         * prevent.
+         *
+         * A column the client really did send carries a DEFINED value — including
+         * an explicit null, which is a caller clearing it — so testing for
+         * definedness is exactly the distinction the guard wanted in the first
+         * place. The update path never had this problem: BaseAPI builds a plain
+         * partial there, holding only the posted keys.
+         */
+        const suppliedCreateKeys = Object.keys(createData || {}).filter((key) => {
+            return createData[key] !== undefined;
+        });
+        /*
+         * Only for a scan that will actually send SNMP. An ICMP-only scan has its
+         * whole SNMP set nulled at the end of this hook, so validating a credential
+         * list it is about to discard would refuse the create over a value nothing
+         * will ever read — and the wizard posts the field whether or not the step
+         * was visible.
+         */
+        const isSnmpEnabledOnCreate = ScanModeUtil.isSnmpEnabled(createBy.data);
+        if (isSnmpEnabledOnCreate) {
+            this.applySnmpConfigs(createData, suppliedCreateKeys);
+        }
+        /*
+         * Every scan leaves this hook WITH a credential list, even one created
+         * through the flattened columns alone (an API caller, an integration
+         * written before this column existed).
+         *
+         * The invariant is what the Edit dialog depends on. That form's only SNMP
+         * control is the list editor, so it selects `snmpConfigs` and nothing else
+         * — a scan whose list were NULL would open with an empty card, and saving
+         * it would replace the credentials the operator could not see. The reader
+         * (SnmpScanConfigUtil.resolve) still falls back to the flattened columns,
+         * because rows written out of band exist; this just means the product
+         * never creates one.
+         */
+        if (isSnmpEnabledOnCreate &&
+            !SnmpScanConfigUtil.readStoredList(createData["snmpConfigs"])) {
+            createData["snmpConfigs"] = SnmpScanConfigUtil.normalizeForStorage(SnmpScanConfigUtil.resolve(createData));
+        }
+        await this.validateProbeIsUsable({
+            data: createBy.data,
+            dataKeys: Object.keys(createBy.data || {}),
+            projectId: createBy.data.projectId || createBy.props.tenantId,
+        });
+        /*
+         * A scan that will not send SNMP stores no SNMP settings. Enforced here
+         * rather than in the form alone, so it holds for a direct API call too —
+         * the same reason the scan target is validated on this hook rather than
+         * only in the wizard.
+         *
+         * Read through ScanModeUtil so an ABSENT flag reads as an SNMP scan, which
+         * is what every scan created before this column existed was, and what
+         * every API client that has never heard of the column means.
+         *
+         * LAST, after nullEmptyNumbers: that pass turns an empty snmpPort box into
+         * null, and this one nulls the whole SNMP set anyway, so running it after
+         * means there is exactly one answer for what an ICMP-only row holds.
+         */
+        if (ScanModeUtil.isIcmpOnly(createBy.data)) {
+            this.clearSnmpConfig(createBy.data);
+        }
         return { createBy, carryForward: null };
     }
     /*
-     * The target column is not user-updatable (its ColumnAccessControl grants no
-     * update permission), but root writers — the probe-ingest endpoints, workers,
-     * migrations — bypass that. Validating any update that carries the column
-     * keeps the invariant true for every writer instead of just the form.
+     * Everything that has to be true of an update before it is allowed to land,
+     * plus the reading of the row that onUpdateSuccess needs and can no longer
+     * take once the write has happened.
+     *
+     * Two classes of writer arrive here. The form, editing a scan's settings —
+     * which is what this hook mostly exists for now (OneUptime issue #3444) —
+     * and the server's own root writers: the probe-ingest endpoints, the
+     * recurring-scan worker, migrations. The root writers carry only run-state
+     * columns and take the cheap exit below without paying for a read.
      */
     async onBeforeUpdate(updateBy) {
-        const dataKeys = Object.keys(updateBy.data || {});
+        var _a;
+        const data = (updateBy.data ||
+            {});
+        const dataKeys = Object.keys(data);
         if (dataKeys.includes("cidr")) {
-            this.validateScanTarget(updateBy.data["cidr"]);
+            this.validateScanTarget(data["cidr"]);
         }
         /*
          * The name IS user-updatable — renaming a scan is the whole point of
@@ -77,11 +279,610 @@ export class Service extends DatabaseService {
          * would try to write.
          */
         if (dataKeys.includes("name")) {
-            const data = updateBy.data;
             this.validateScanName(data["name"]);
             data["name"] = ScanNameUtil.normalize(data["name"]);
         }
-        return { updateBy, carryForward: null };
+        this.nullEmptyNumbers(data, dataKeys);
+        /*
+         * Turning the method off clears the credentials in the same statement, so
+         * the row can never say "sends no SNMP" while carrying a community string
+         * or a v3 passphrase (issue #3445). The edit form posts every declared
+         * field regardless of visibility, so the SNMP boxes the operator just hid
+         * are still in this payload.
+         *
+         * Gated on the key being WRITTEN, not merely on the stored value being
+         * false: a rename, or the probe-ingest endpoints writing run state, must
+         * not reach in and null a column they never mentioned. `data` is mutated
+         * in place because onUpdateSuccess is handed back the same updateBy object.
+         */
+        const isTurningSnmpOff = dataKeys.includes("isSnmpEnabled") && ScanModeUtil.isIcmpOnly(data);
+        if (isTurningSnmpOff) {
+            this.clearSnmpConfig(data);
+        }
+        else {
+            /*
+             * Runs BEFORE isSweepWritten is computed, because it can ADD the
+             * flattened SNMP columns to the payload — and those are sweep columns. A
+             * mirror written after that flag was read would be invisible to the
+             * reconciliation and could hand the probe one credential while the row
+             * advertised another.
+             *
+             * Skipped entirely when the save is turning SNMP OFF, and that is not
+             * merely an optimisation: this pass VALIDATES the credential list, and
+             * the form posts every declared field whether or not it was visible. An
+             * operator who unticked Check SNMP would otherwise be refused their save
+             * over a half-finished credential set they had just told the product to
+             * stop using. clearSnmpConfig nulls the list along with the flattened
+             * columns, so there is nothing left to validate.
+             */
+            this.applySnmpConfigs(data, dataKeys);
+        }
+        const dataKeysAfterMirror = Object.keys(data);
+        const isSweepWritten = RelationIdUtil.isWritten(dataKeysAfterMirror, PROBE_RELATION_KEYS) ||
+            SWEEP_COLUMNS.some((column) => {
+                return dataKeysAfterMirror.includes(column);
+            });
+        const isScheduleWritten = SCHEDULE_COLUMNS.some((column) => {
+            return dataKeysAfterMirror.includes(column);
+        });
+        /*
+         * THE CHEAP EXIT, and it is load-bearing rather than an optimisation.
+         *
+         * Every server-side writer of this model touches run state only — the
+         * claim writes status/startedAt/statusMessage, the result ingest writes
+         * the results, the requeue worker and the stale-scan reaper write status
+         * and timestamps, the unclaimed-diagnosis pass writes statusMessage. None
+         * of them carries a sweep or schedule column, so none of them reads a row
+         * here, and none can trip the reconciliation below into retiring the very
+         * result it is in the middle of storing.
+         *
+         * `updateBy` is also handed back as the SAME object, which is what
+         * Common/Tests/Server/Services/DiscoveryScanClaimHookFreeSafety.test.ts
+         * pins: the claim's hook-free write is only safe while this hook is a
+         * pass-through for the claim's payload.
+         */
+        if (!isSweepWritten && !isScheduleWritten) {
+            return { updateBy, carryForward: null };
+        }
+        /*
+         * Scoped by hand, because this hook runs BEFORE
+         * ModelPermission.checkUpdateQueryPermissions and BaseAPI hands the
+         * service a bare `{_id}` query — so reading with the caller's own query as
+         * root, unscoped, would answer "does this id exist, and what are its
+         * credentials" for every project on the instance. Same shape as
+         * MonitorService.onBeforeUpdate.
+         */
+        const scans = await this.findBy({
+            query: !updateBy.props.isRoot && updateBy.props.tenantId
+                ? Object.assign(Object.assign({}, updateBy.query), { projectId: updateBy.props.tenantId }) : updateBy.query,
+            select: {
+                _id: true,
+                projectId: true,
+                cidr: true,
+                probeId: true,
+                snmpConfigs: true,
+                snmpVersion: true,
+                snmpCommunityString: true,
+                snmpPort: true,
+                snmpV3SecurityLevel: true,
+                snmpV3Username: true,
+                snmpV3AuthProtocol: true,
+                snmpV3AuthKey: true,
+                snmpV3PrivProtocol: true,
+                snmpV3PrivKey: true,
+            },
+            limit: LIMIT_MAX,
+            skip: 0,
+            props: {
+                isRoot: true,
+                ignoreHooks: true,
+            },
+        });
+        const plans = {};
+        for (const scan of scans) {
+            const scanId = (_a = scan._id) === null || _a === void 0 ? void 0 : _a.toString();
+            if (!scanId) {
+                continue;
+            }
+            /*
+             * Checked per matched scan, because the answer depends on which project
+             * the scan belongs to — and read from the row rather than from the
+             * caller's tenant, so a root writer is held to the same rule.
+             */
+            await this.validateProbeIsUsable({
+                data: data,
+                dataKeys: dataKeysAfterMirror,
+                projectId: scan.projectId,
+            });
+            const isLegacySnmpWritten = this.reconcileLegacySnmpUpdate({
+                data: data,
+                dataKeys: dataKeysAfterMirror,
+                scan: scan,
+            });
+            plans[scanId] = {
+                isSweepChanged: isSweepWritten
+                    ? this.hasSweepChanged(scan, data, dataKeysAfterMirror)
+                    : false,
+                isScheduleWritten: isScheduleWritten,
+                isLegacySnmpWritten: isLegacySnmpWritten,
+            };
+        }
+        return { updateBy, carryForward: plans };
+    }
+    /*
+     * Put the row back into a state that describes itself honestly.
+     *
+     * Two things can be wrong the moment a settings edit lands, and neither can
+     * be fixed in the update itself: the columns that would fix them
+     * (status, nextScanAt, the result columns) grant no update permission to
+     * anybody, and ModelPermission checks the payload AFTER onBeforeUpdate has
+     * run — so a payload carrying them would be refused for the very user doing
+     * the editing. They are written here instead, as root, through the same
+     * hook-free single-statement path the probe's claim uses.
+     *
+     *   1. A changed target, probe or credential leaves the row advertising
+     *      hosts from a sweep that is no longer the sweep this scan describes:
+     *      "12 of 254 hosts" beside a range it never visited, a Review Results
+     *      dialog offering them for import under the new credentials, and an
+     *      auto-import worker willing to create devices from them. The run is
+     *      retired and the scan re-queued, so the probe simply sweeps again.
+     *
+     *   2. nextScanAt is derived state that only the result-ingest endpoint used
+     *      to write. Turning recurrence ON for a scan that had already finished
+     *      therefore scheduled nothing at all — the column stayed NULL, and the
+     *      requeue worker's `nextScanAt <= now` is never true of NULL — so the
+     *      list said "Every 60 min" over a scan that would never run again.
+     *      Shortening the interval had the same shape of bug: the new cadence
+     *      only took effect one full old cadence later.
+     *
+     * A known and deliberate gap: this is a second statement, so between the two
+     * writes the row briefly holds the new settings with the old run state. Two
+     * things can go wrong inside that window, both of them one database round
+     * trip wide. A probe result landing there is stamped onto the new settings;
+     * closing that needs the probe to echo a run identity back, which is a probe
+     * protocol change. And if this write itself fails while the settings write
+     * succeeded, the row keeps the new settings with the old results until the
+     * next edit that actually changes something — the operator sees the error,
+     * but re-saving the same values will not repair it, because by then nothing
+     * has changed.
+     *
+     * Doing it FIRST instead, in onBeforeUpdate, would be worse rather than
+     * better: that hook runs before the row-level gate as well, so a caller
+     * whose update is about to be refused would have retired the scan on the way
+     * through.
+     */
+    async onUpdateSuccess(onUpdate, updatedItemIds) {
+        const plans = onUpdate.carryForward || null;
+        if (!plans) {
+            return onUpdate;
+        }
+        const now = OneUptimeDate.getCurrentDate();
+        for (const itemId of updatedItemIds) {
+            const plan = plans[itemId.toString()];
+            if (!plan) {
+                continue;
+            }
+            /*
+             * Nothing to do at all: the save named a setting but changed none of
+             * them, and never mentioned the schedule.
+             */
+            if (!plan.isSweepChanged &&
+                !plan.isScheduleWritten &&
+                !plan.isLegacySnmpWritten) {
+                continue;
+            }
+            /*
+             * The row as it stands now that the update has landed. Read rather than
+             * predicted from the payload: the schedule columns are what the next run
+             * is derived from, and reading them back means the derivation sees the
+             * values the DATABASE holds — properly typed — instead of whatever
+             * shape the request happened to send them in.
+             */
+            const scan = await this.findOneById({
+                id: itemId,
+                select: {
+                    status: true,
+                    isRecurring: true,
+                    rescanIntervalInMinutes: true,
+                    completedAt: true,
+                    nextScanAt: true,
+                    /*
+                     * For the legacy-write rebuild below. Read back rather than taken
+                     * from the payload, so the list is built from the values the
+                     * database actually holds — the payload may have named only some of
+                     * them, and the rest are whatever the row already had.
+                     */
+                    isSnmpEnabled: true,
+                    snmpVersion: true,
+                    snmpCommunityString: true,
+                    snmpPort: true,
+                    snmpV3SecurityLevel: true,
+                    snmpV3Username: true,
+                    snmpV3AuthProtocol: true,
+                    snmpV3AuthKey: true,
+                    snmpV3PrivProtocol: true,
+                    snmpV3PrivKey: true,
+                },
+                props: {
+                    isRoot: true,
+                    ignoreHooks: true,
+                },
+            });
+            // Hard-deleted between the write and this read. Nothing to reconcile.
+            if (!scan) {
+                continue;
+            }
+            const reconcile = plan.isSweepChanged
+                ? Object.assign({}, RETIRE_RUN_PAYLOAD) : {};
+            /*
+             * The save came through the old single-credential API, so put the list
+             * back in step with the flattened columns it just wrote.
+             *
+             * Rebuilt from the ROW, which is why it happens here: one update payload
+             * is shared by every row the query matched, and the values to rebuild
+             * from are per row. resolve() over a row with no list synthesizes exactly
+             * one config from those columns, which is the whole of a
+             * single-credential scan — reconcileLegacySnmpUpdate has already refused
+             * the case where the row has more.
+             *
+             * An ICMP-only scan is skipped: it stores no SNMP settings at all, and
+             * materializing a list of the nulls it holds would be a credential set
+             * that says nothing, on a scan that sends nothing.
+             */
+            if (plan.isLegacySnmpWritten && ScanModeUtil.isSnmpEnabled(scan)) {
+                reconcile["snmpConfigs"] = SnmpScanConfigUtil.normalizeForStorage(SnmpScanConfigUtil.resolve(scan));
+            }
+            /*
+             * Only a save that changed the sweep or asked about the schedule gets
+             * its next run re-derived — and the gate has to be stated here rather
+             * than left to the early `continue` above.
+             *
+             * It used to be left to it: that exit returned unless the sweep had
+             * changed or the schedule was written, so nothing else could reach this.
+             * Adding the credential-list rebuild to that condition opened a third
+             * way in, and a save through the flattened columns alone — which asks
+             * about neither — began re-deriving the column. On a recurring scan the
+             * stale-scan reaper had made due immediately (nextScanAt pulled back to
+             * completedAt so the requeue worker picks it up now), that pushed the
+             * recovery a full cadence into the future for a save that changed
+             * nothing about when the scan should run.
+             *
+             * For a retired run the state to derive from is the queued one written
+             * just above, not the finished one the row still shows.
+             */
+            if (plan.isSweepChanged || plan.isScheduleWritten) {
+                const nextScanAt = getNextScanAt({
+                    isRecurring: scan.isRecurring,
+                    rescanIntervalInMinutes: scan.rescanIntervalInMinutes,
+                    status: plan.isSweepChanged ? "Pending" : scan.status,
+                    completedAt: plan.isSweepChanged ? null : scan.completedAt,
+                }, now);
+                if (!this.isSameMoment(nextScanAt, scan.nextScanAt)) {
+                    reconcile["nextScanAt"] = nextScanAt;
+                }
+            }
+            if (Object.keys(reconcile).length === 0) {
+                continue;
+            }
+            await this.updateColumnsByIdWithoutHooks({
+                id: itemId,
+                // Cast: the model's JSON column makes DeepPartial recursion blow up.
+                data: reconcile,
+            });
+        }
+        return onUpdate;
+    }
+    /*
+     * Whether this update actually changes what the probe would sweep.
+     *
+     * VALUE comparison, never key presence: ModelForm posts every field it
+     * declares on every save, dirty or not, so an operator who opened Edit and
+     * pressed Save without typing sends the whole sweep back verbatim. Keyed on
+     * presence, that would retire a good result set on every no-op save.
+     */
+    hasSweepChanged(scan, data, dataKeys) {
+        var _a;
+        if (RelationIdUtil.isWritten(dataKeys, PROBE_RELATION_KEYS)) {
+            const probeId = RelationIdUtil.read(data, PROBE_RELATION_KEYS);
+            if ((probeId === null || probeId === void 0 ? void 0 : probeId.toString()) !== ((_a = scan.probeId) === null || _a === void 0 ? void 0 : _a.toString())) {
+                return true;
+            }
+        }
+        for (const column of SWEEP_COLUMNS) {
+            if (column === "probeId" || !dataKeys.includes(column)) {
+                continue;
+            }
+            if (this.normalizeSweepValue(data[column]) !==
+                this.normalizeSweepValue(scan[column])) {
+                return true;
+            }
+        }
+        return false;
+    }
+    /*
+     * The probe a scan is pointed at has to be one this project may actually use
+     * — its own, or a global one.
+     *
+     * The scan is dispatched by probe id alone: the claim endpoint hands a
+     * Pending scan to whichever probe authenticates as that id, with no project
+     * check of its own, and the results are written back onto this row. So a
+     * scan pointing at ANOTHER project's probe is a scan that makes that
+     * project's probe sweep its own network and report the hosts it finds into
+     * this one. The ids are not guessable and the probe list is tenant-scoped,
+     * so this is a lock rather than a repair — but it is the lock that has to
+     * exist now that the column can be re-pointed after creation, and it is
+     * applied on create for the same reason.
+     *
+     * A probe with no project is a global probe and is available to everyone.
+     */
+    async validateProbeIsUsable(input) {
+        if (!RelationIdUtil.isWritten(input.dataKeys, PROBE_RELATION_KEYS)) {
+            return;
+        }
+        /*
+         * readConsistent, not read: a payload that points the FK column and the
+         * relation object at two different probes must be refused rather than
+         * validated against whichever one TypeORM happens to persist.
+         */
+        const probeId = RelationIdUtil.readConsistent(input.data, PROBE_RELATION_KEYS, "Probe");
+        /*
+         * probeId is NOT NULL, so a payload that names the probe and resolves to
+         * nothing is an operator clearing the box. Without this it reaches
+         * Postgres as a constraint violation — a 500 where the truthful answer is
+         * a 400 with a sentence in it.
+         */
+        if (!probeId) {
+            throw new BadDataException("A discovery scan needs a probe to run it. Pick the probe that can reach this address range.");
+        }
+        // Nothing to compare against; the write itself is still tenant-checked.
+        if (!input.projectId) {
+            return;
+        }
+        const probe = await ProbeService.findOneById({
+            id: probeId,
+            select: {
+                _id: true,
+                projectId: true,
+            },
+            props: {
+                isRoot: true,
+            },
+        });
+        if (!probe) {
+            throw new BadDataException("That probe could not be found. Pick a probe that can reach this address range.");
+        }
+        if (probe.projectId &&
+            probe.projectId.toString() !== input.projectId.toString()) {
+            throw new BadDataException("That probe belongs to another project. Pick one of this project's probes, or a global probe.");
+        }
+    }
+    /*
+     * An emptied number box means "unset", not "the empty string".
+     *
+     * Written in place, like the name normalization above, so the value the rest
+     * of the pipeline sees is the value that will be stored.
+     */
+    nullEmptyNumbers(data, dataKeys) {
+        for (const column of NULLABLE_NUMBER_COLUMNS) {
+            if (!dataKeys.includes(column)) {
+                continue;
+            }
+            const value = data[column];
+            if (typeof value === "string" && value.trim() === "") {
+                data[column] = null;
+            }
+        }
+    }
+    /*
+     * A sweep column's value as a comparable string.
+     *
+     * An empty box and an unset column are the SAME setting and must compare
+     * equal, or a V3 scan — whose community string is NULL in the database and
+     * "" in the form — would read as changed on the first save and retire its
+     * own results. Numbers are compared as numbers so the port arriving as the
+     * string "161" from a form field does not read as a change either.
+     */
+    normalizeSweepValue(value) {
+        if (value === undefined || value === null || value === "") {
+            return "";
+        }
+        if (typeof value === "number") {
+            return String(value);
+        }
+        if (typeof value === "string") {
+            return value.trim();
+        }
+        /*
+         * The credential LIST, and the reason the fall-through below cannot be
+         * left to speak for it: `String([{ ... }])` is "[object Object]" for every
+         * possible list, so two completely different sets of credentials would
+         * compare equal and a save that swapped them would leave the row
+         * advertising hosts found with the old ones.
+         *
+         * Compared through the same normalizer the probe and the importer read the
+         * column with, so the comparison is of the credentials that will actually
+         * be USED — an empty box against an unset field, "161" against 161, "V3"
+         * against "3" — rather than of the shape the form happened to post. That
+         * is what stops a no-op Save (ModelForm posts every field, dirty or not)
+         * from retiring a good result set on every visit to the Edit dialog.
+         *
+         * An empty array normalizes to "" — the same answer as an unset column —
+         * because both mean "this scan has no list of its own". A list is refused
+         * as empty at validation time anyway; this only decides whether the two
+         * shapes read as a CHANGE.
+         */
+        if (Array.isArray(value)) {
+            /*
+             * Compared on what the PROBE would do differently, which is neither the
+             * whole stored object nor a naive stringify of it. Two fields are
+             * deliberately excluded, and each one caused a real bug:
+             *
+             *   - `name` is the operator's label. It reaches a log line and the
+             *     scan's status message and nothing else — never the wire. Including
+             *     it meant renaming a credential card retired the run and deleted
+             *     every host the scan had found, for a change that alters nothing
+             *     about the sweep.
+             *   - `id` is server-minted bookkeeping. applySnmpConfigs runs BEFORE
+             *     this comparison and mints a fresh ObjectID for any entry that
+             *     arrived without one, so a client that does not echo ids back — an
+             *     API caller, a reconciler re-applying the same desired state — sent
+             *     a byte-identical body twice and had the second read as a credential
+             *     change. A scan under such a reconciler could never hold a result
+             *     set at all.
+             *
+             * What survives is exactly the session parameters: version, community,
+             * port and the v3 block, in the operator's order. A REORDER still reads
+             * as a change, because order decides which credential each host is tried
+             * with first.
+             *
+             * Through resolve(), NOT normalizeForStorage(): the latter mints ids, and
+             * a comparison has to be a pure function of its input.
+             */
+            const configs = SnmpScanConfigUtil.resolve({
+                snmpConfigs: value,
+            });
+            const sweepShape = configs.map((config) => {
+                const sweepFields = Object.assign({}, config);
+                delete sweepFields["id"];
+                delete sweepFields["name"];
+                return sweepFields;
+            });
+            return value.length === 0 ? "" : JSON.stringify(sweepShape);
+        }
+        return String(value);
+    }
+    /*
+     * An update written through the FLATTENED columns alone, on a scan that has
+     * a credential list.
+     *
+     * The list shadows those columns — SnmpScanConfigUtil.resolve reads it and
+     * ignores them — so such a write would land in the database and change
+     * nothing about the sweep, which is the worst of both outcomes: the caller
+     * is told it succeeded and the scan keeps the credentials it had.
+     *
+     * There are exactly two honest answers, and which one applies depends only
+     * on how many configs the row holds:
+     *
+     *   - ONE (or none): the scan is single-credential, so the flattened columns
+     *     can describe it completely. This returns true and onUpdateSuccess
+     *     REBUILDS the list from the row's own flattened columns once the write
+     *     has landed — the behaviour this API had before the list existed, with
+     *     the list kept in step rather than discarded.
+     *   - MORE THAN ONE: there is no flattened column set that could express the
+     *     scan, and picking one config to overwrite would silently discard the
+     *     others. Refused, naming the field to use instead.
+     *
+     * It does NOT null the column, which is what it used to do. A NULL list is
+     * readable — SnmpScanConfigUtil.resolve falls back to the flattened columns
+     * — but it is not EDITABLE: the Edit dialog's only SNMP control is the list
+     * editor, so it selects `snmpConfigs` alone, and a NULL there opened a blank
+     * card over a scan that had real credentials. Saving that card then mirrored
+     * its emptiness back over all nine columns and wiped them. The invariant
+     * "every scan the product has touched has a list" is what makes that
+     * unreachable, and this is the third place that maintains it, after the
+     * backfill migration and onBeforeCreate.
+     */
+    reconcileLegacySnmpUpdate(input) {
+        if (input.dataKeys.includes("snmpConfigs")) {
+            return false;
+        }
+        const isLegacyColumnWritten = LEGACY_SNMP_COLUMNS.some((column) => {
+            return input.dataKeys.includes(column);
+        });
+        if (!isLegacyColumnWritten) {
+            return false;
+        }
+        const stored = SnmpScanConfigUtil.readStoredList(input.scan.snmpConfigs);
+        if (stored && stored.length > 1) {
+            throw new BadDataException(`This scan tries ${stored.length} SNMP configs, which the single snmp* fields cannot describe. ` +
+                `Send the whole "snmpConfigs" list instead.`);
+        }
+        return true;
+    }
+    /*
+     * The scan's ordered SNMP credential list: validated, normalized, and
+     * mirrored into the flattened columns.
+     *
+     * Called from BOTH write hooks, and a no-op for a payload that does not
+     * mention `snmpConfigs` — which is every server-side writer of this model
+     * (the probe claim, the result ingest, the requeue worker) and every API
+     * caller still using the flattened columns alone.
+     *
+     * THE MIRROR IS THE POINT. A probe is deployed separately from the server
+     * and is routinely a version behind, and a probe that has never heard of
+     * `snmpConfigs` reads the flattened columns and nothing else. Without this,
+     * saving a multi-config scan would leave those columns holding whatever the
+     * scan was created with — or, for a scan created after this feature, the
+     * bare column defaults — and every older probe in the fleet would sweep with
+     * "public"/v2c and report a confident zero. Mirroring the FIRST config keeps
+     * such a probe doing exactly what it would have done under the old
+     * single-config UI.
+     */
+    applySnmpConfigs(data, dataKeys) {
+        var _a;
+        if (!dataKeys.includes("snmpConfigs")) {
+            return;
+        }
+        const raw = data["snmpConfigs"];
+        /*
+         * An absent list is not the same as a bad one. The edit form always posts
+         * the key, so a null/empty value here is an API caller clearing the column
+         * — which puts the scan back on its flattened columns, exactly where a
+         * scan created before this feature already is. Nothing is mirrored in that
+         * case: there is no first config to mirror from, and overwriting the
+         * flattened columns with defaults would erase the credentials that clearing
+         * the list just fell back to.
+         */
+        if (raw === undefined || raw === null || raw === "") {
+            data["snmpConfigs"] = null;
+            return;
+        }
+        const validationError = SnmpScanConfigUtil.getValidationError(raw);
+        if (validationError) {
+            throw new BadDataException(validationError);
+        }
+        const configs = SnmpScanConfigUtil.normalizeForStorage(raw);
+        data["snmpConfigs"] = configs;
+        if (!configs || configs.length === 0) {
+            return;
+        }
+        const mirrored = SnmpScanConfigUtil.getMirroredLegacyColumns(configs);
+        for (const column of Object.keys(mirrored)) {
+            /*
+             * The payload wins where it speaks for itself. An API caller that sends
+             * BOTH the list and a flattened column meant the flattened one, and
+             * silently overwriting it would make the two disagree in a way only the
+             * database could reveal.
+             */
+            if (dataKeys.includes(column)) {
+                continue;
+            }
+            data[column] = (_a = mirrored[column]) !== null && _a !== void 0 ? _a : null;
+        }
+    }
+    /*
+     * Two nullable timestamps, compared by the instant they name. The stored
+     * value comes back from Postgres and the derived one is built here, so a
+     * strict equality between the two objects is never true even when the moment
+     * is identical, and every no-op save would write the column again.
+     */
+    isSameMoment(left, right) {
+        if (!left || !right) {
+            return !left && !right;
+        }
+        return (OneUptimeDate.fromString(left).getTime() ===
+            OneUptimeDate.fromString(right).getTime());
+    }
+    /*
+     * Written through a cast for the same reason the name normalize above is:
+     * the properties are typed `string | number | undefined` and
+     * exactOptionalPropertyTypes forbids assigning null to them directly.
+     */
+    clearSnmpConfig(data) {
+        const record = data;
+        for (const column of Service.SNMP_CONFIG_COLUMNS) {
+            record[column] = null;
+        }
     }
     /*
      * The value is passed through UNTOUCHED. It arrives straight from the
@@ -114,6 +915,41 @@ export class Service extends DatabaseService {
         }
     }
 }
+/*
+ * The columns an ICMP-only scan must not carry (OneUptime issue #3445).
+ *
+ * Hiding the fields in the form is not enough on its own, for two separate
+ * reasons. ModelForm builds the request body out of every DECLARED field
+ * without checking whether it was visible, so a v3 passphrase typed before
+ * the operator changed their mind is still posted — and TypeORM OMITS an
+ * undefined property from the INSERT, at which point Postgres fills in the
+ * column defaults, which for this table are 'V2c' and 161. Either way the
+ * stored row claims to be an SNMP v2c scan on port 161 while its own method
+ * column says it sends no SNMP at all.
+ *
+ * An explicit null is the only value that beats a column default, which is
+ * why these are nulled rather than deleted.
+ */
+Service.SNMP_CONFIG_COLUMNS = [
+    /*
+     * The credential LIST belongs here as much as the flattened columns do,
+     * and more urgently: it is where the community strings and v3 passphrases
+     * of a multi-credential scan actually live (issue #3458). Clearing the
+     * nine below while leaving this behind would store an ICMP-only scan whose
+     * own method column says it sends no SNMP, carrying every credential the
+     * operator had typed.
+     */
+    "snmpConfigs",
+    "snmpVersion",
+    "snmpCommunityString",
+    "snmpPort",
+    "snmpV3SecurityLevel",
+    "snmpV3Username",
+    "snmpV3AuthProtocol",
+    "snmpV3AuthKey",
+    "snmpV3PrivProtocol",
+    "snmpV3PrivKey",
+];
 __decorate([
     CaptureSpan(),
     __metadata("design:type", Function),
@@ -126,5 +962,11 @@ __decorate([
     __metadata("design:paramtypes", [Object]),
     __metadata("design:returntype", Promise)
 ], Service.prototype, "onBeforeUpdate", null);
+__decorate([
+    CaptureSpan(),
+    __metadata("design:type", Function),
+    __metadata("design:paramtypes", [Object, Array]),
+    __metadata("design:returntype", Promise)
+], Service.prototype, "onUpdateSuccess", null);
 export default new Service();
 //# sourceMappingURL=NetworkDeviceDiscoveryScanService.js.map