clearCacheOnVersionChange() throws ERR_INVALID_ARG_TYPE on every launch – getUserDataPath() called with no argument, so the post-update cach

getUserDataPath(subPath) in src/process-manager.js does path.join(app.getPath('userData'), subPath). clearCacheOnVersionChange() in src/main.js calls it with NO argument, so subPath is undefined and path.join() throws ERR_INVALID_ARG_TYPE on the function's very first statement.

The surrounding try/catch swallows it as a log.warn, so nothing surfaces to the user and the app carries on normally. The result is that clearCacheOnVersionChange() has never done anything at all – it fails before it reads the marker, before it compares versions, and before it reaches session.defaultSession.clearCache().

CONFIRMED TWO INDEPENDENT WAYS on this install:
1. The marker file frontend-cache-version.txt does not exist in userData. It is only written inside the if-block that follows the throwing line, so its absence proves the function has never completed.
2. The log line 'App version changed (… -> …); clearing renderer cache' appears ZERO times across main.log and main.old.log, while the warning appears 10 times in main.log alone – once per launch.

IMPACT: the exact failure mode the function's own comment describes is unguarded. That comment reads: 'After an app update, force the renderer to drop its cached frontend so the new bundle (with new content-hashed asset names) is actually loaded. Without this, a cached index.html keeps referencing the previous build's assets and the UI appears unchanged despite the version bump.' Since the frontend is served over HTTP from the local backend, index.html is a normal cacheable response, so that scenario is live and nothing is preventing it.

SCOPE HONESTY – this is NOT currently biting on this machine, and it is NOT the cause of the black-window bug I filed separately. I checked: frontend asset requests return only 200 and 304, no 404s, so no stale-asset breakage is happening right now. I am reporting it as a latent defect found while reading logs, not as an active outage. Filing it because it is silently dead code guarding a real failure mode, and because 'the UI looks unchanged after updating' is the kind of report that would be very hard to diagnose with this function quietly doing nothing.

PLATFORM: cross-platform. path.join(string, undefined) throws on macOS and Linux too, so this is not Windows-specific – it is simply invisible everywhere.

FIX: either give getUserDataPath a default (subPath = '') or call it as getUserDataPath('frontend-cache-version.txt') and drop the path.join at the call site. Worth also reconsidering whether this failure deserves log.warn inside a catch-all – a broken cache-invalidation step arguably wants to be louder than a warning nobody reads.

Related: see the separate report on Windows enable-features=Vulkan causing a blank window on maximise (topic 1214). Different bug, same install, found in the same log sweep.

Steps to reproduce
1. Launch GreenLight DashBoard on any platform.
2. Open main.log in the userData logs folder.
3. Observe the clearCacheOnVersionChange warning with an ERR_INVALID_ARG_TYPE stack, on this launch and every previous one.
4. Check userData for frontend-cache-version.txt – it is absent.
5. Grep the logs for 'clearing renderer cache' – zero hits, at any version transition, including across an actual 10.2.0 update that the same log records.

Expected
On a version change, clearCacheOnVersionChange() clears the renderer HTTP cache, logs 'App version changed (X -> Y); clearing renderer cache', and writes frontend-cache-version.txt so the next launch is a no-op.

Actual
The function throws ERR_INVALID_ARG_TYPE on its first statement every launch, the catch downgrades it to a warning, the cache is never cleared and the marker file is never written. Silent no-op since introduction.

Error output

# From main.log - one occurrence per launch, 10 in the current file:
[warn]  clearCacheOnVersionChange failed: TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined
    at Object.join (node:path:479:7)
    at getUserDataPath (resources/app.asar/src/process-manager.js:35:15)
    at clearCacheOnVersionChange (resources/app.asar/src/main.js:72:30)
    at createWindow (resources/app.asar/src/main.js:125:9)
    at startup (resources/app.asar/src/main.js:411:9)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

# src/process-manager.js:34-36
function getUserDataPath(subPath) {
  return path.join(app.getPath('userData'), subPath);   // subPath === undefined
}

# src/main.js, inside clearCacheOnVersionChange - the throwing call site:
const marker = path.join(getUserDataPath(), 'frontend-cache-version.txt');

# Evidence the function has never succeeded:
userData/frontend-cache-version.txt          -> does not exist
grep -c 'clearing renderer cache' main.log     -> 0
grep -c 'clearing renderer cache' main.old.log -> 0
grep -c 'clearCacheOnVersionChange failed' main.log -> 10

# Not currently causing stale assets on this install:
frontend /assets/* responses observed: 200 and 304 only, no 404s.

Context
Feature area: Electron main process / app update + renderer cache invalidation.
Affected functions: getUserDataPath (src/process-manager.js:34), clearCacheOnVersionChange (src/main.js), called from createWindow -> startup.
App version: 10.2.0 (warning also present in the immediately preceding version at a different line number, so not a 10.2.0 regression).
Electron 33.4.11 / Chromium 130.0.6723.191
OS observed on: Windows 11 Pro 10.0.26200 – but the defect is platform-independent.
Severity: low and latent, no current user-visible breakage. Reported as a correctness bug, not an outage.

Environment
App version: 10.2.0
Platform: Windows 11 (AMD64)