fix(domain-updater): don't clobber existing SSL data with empty values

[firstlayerdigital]

Summary

• When the SSL cert fetch in domain-info fails for a domain (e.g. an apex with no A record, so the tls.connect() call rejects with No address associated with hostname), the endpoint returns empty strings for all SSL fields.
• The updateSSL INSERT path handles this fine — it coerces "" to NULL via toDateOnly(x) || null, so the first run quietly inserts a row of nulls.
• Every subsequent run then crashes in the UPDATE path, because the code pushes empty strings to ::date casts, which Postgres rejects with invalid input syntax for type date: "".
• Secondary (same root cause): the text/int path can clobber a previously-good issuer / subject / fingerprint / key_size with "" / 0 when a fetch partially fails — field.new ?? null falls through to the empty string because ?? doesn't catch empty strings.

The bug in practice

First run (INSERT), fine:

"domain":"apex-with-no-a-record.com","changes":["SSL created"]

Second run (UPDATE), crashes:

"domain":"apex-with-no-a-record.com","changes":["SSL Valid From","SSL Valid To","(⚠️ Error in updateSSL: pgExecutor HTTP 500: { \"error\": \"invalid input syntax for type date: \\\"\\\"\" })"]

Root cause walkthrough

In the UPDATE loop (src/server/routes/domain-updater/updateFns/ssl.ts):

if (field.type === 'date') {
  const oldDate = new Date(oldVal);
  const newDate = new Date(newVal);              // new Date("") -> Invalid Date
  const diffInMs = Math.abs(newDate.getTime() - oldDate.getTime()); // NaN
  const diffInDays = diffInMs / (1000 * 60 * 60 * 24);              // NaN
  if (isNaN(diffInDays) || diffInDays > 1) {                        // true
    updateSet.push(`${field.column} = \$${updateSet.length + 2}::date`);
    updateValues.push(toDateOnly(newVal));       // "" goes in as $N
    // ... later: `UPDATE ... SET valid_from = $2::date ...` with $2 = ""
  }
}

Postgres then rejects the ""::date cast.

Fix

Skip the iteration entirely when newVal is empty (applies to dates, text, and int uniformly), and add an Invalid-Date guard in the date branch:

// If the fresh fetch didn't produce a value for this field (e.g. the SSL
// fetch failed upstream), don't clobber existing data with an empty string.
// For date columns this also prevents `""::date` casts which Postgres rejects.
if (!newVal) continue;

if (field.type === 'date') {
  const newDate = new Date(newVal);
  if (isNaN(newDate.getTime())) continue;
  const oldDate = new Date(oldVal);
  // ... rest unchanged
}

This preserves existing SSL data when fetches partially fail, which matches the behavior a domain portfolio tracker should have — stale cert info is more useful than blanked-out cert info.

Note: field.new ?? null on line 96 still falls through to "" for empty strings (since ?? only catches null/undefined), but the new if (!newVal) continue; guard above now prevents that path from being reached with an empty value. Left the existing ?? in place to minimize diff; could be tightened to field.new || null in a follow-up if you want belt-and-suspenders.

Test plan

• Repro: self-hosted instance (DL_ENV_TYPE=selfHosted), add an apex domain with no A record, hit /domain-updater twice. Before: crashes on second run with invalid input syntax for type date: "". After: returns "No changes, all data is up-to-date".
• Verified the patched compiled .mjs bundle runs on CT 113 (Node 22, Postgres 17) against 6 real domains including one apex with no A record; the other 5 domains continue to pick up legitimate SSL field changes (e.g. SSL Key Size diffs) without regression.
• ng test — the existing test suite targets Angular components (src/app/app.component.spec.ts) and doesn't cover the server-side updateFns/, so there's nothing to run against this change. Happy to add a unit test for updateSSL if you'd like.

Unrelated note (separate from this PR)

The community-scripts/ProxmoxVE install script for Domain Locker does not install the whois system package. This breaks WHOIS lookups for .io, .app, and some other TLDs that the whois-json npm lib doesn't handle — the native-binary fallback in src/server/utils/whois.ts silently fails because whois isn't in PATH. I'll file that separately on community-scripts.

[vercel]

@firstlayerdigital is attempting to deploy a commit to the AS93 Team on Vercel.

A member of the Team first needs to authorize it.