hcengineering/platform · warning · Error

Unexpected exception: could not detect node path or script p

Error message

Unexpected exception: could not detect node path or script path

What it means

loadCollabYdoc in foundations/server/packages/collaboration/src/storage.ts logs ctx.warn('invalid content type') when the blob's contentType does not include 'application/ydoc'. Notably it only warns and continues — the function still loads the blob and parses it as a YDoc, so this is a data-hygiene signal that a document stored with an unexpected content type is being opened as a collaboration ydoc.

Source

Thrown at foundations/communication/common/scripts/install-run-rush.js:165

}
function _getBin(scriptName) {
    switch (scriptName.toLowerCase()) {
        case 'install-run-rush-pnpm.js':
            return 'rush-pnpm';
        case 'install-run-rushx.js':
            return 'rushx';
        default:
            return 'rush';
    }
}
function _run() {
    const [nodePath /* Ex: /bin/node */, scriptPath /* /repo/common/scripts/install-run-rush.js */, ...packageBinArgs /* [build, --to, myproject] */] = process.argv;
    // Detect if this script was directly invoked, or if the install-run-rushx script was invokved to select the
    // appropriate binary inside the rush package to run
    const scriptName = path__WEBPACK_IMPORTED_MODULE_0__.basename(scriptPath);
    const bin = _getBin(scriptName);
    if (!nodePath || !scriptPath) {
        throw new Error('Unexpected exception: could not detect node path or script path');
    }
    let commandFound = false;
    let logger = { info: console.log, error: console.error };
    for (const arg of packageBinArgs) {
        if (arg === '-q' || arg === '--quiet') {
            // The -q/--quiet flag is supported by both `rush` and `rushx`, and will suppress
            // any normal informational/diagnostic information printed during startup.
            //
            // To maintain the same user experience, the install-run* scripts pass along this
            // flag but also use it to suppress any diagnostic information normally printed
            // to stdout.
            logger = {
                info: () => { },
                error: console.error
            };
        }
        else if (!arg.startsWith('-') || arg === '-h' || arg === '--help') {
            // We either found something that looks like a command (i.e. - doesn't start with a "-"),

View on GitHub (pinned to 63e28dc964)

Solutions

  1. If the document loads fine, treat this as informational — optionally fix the blob's contentType metadata in storage.
  2. Verify the blobId being passed corresponds to a ydoc object, not another attachment.
  3. Re-save/migrate the document through the current version so it is stored with contentType application/ydoc.
  4. If parsing subsequently fails, restore the document from backup or re-create it, since the stored bytes are not valid ydoc content.
Defensive patterns

Strategy: validation

Validate before calling

const blob = await storageAdapter.stat(ctx, wsIds, blobId)
if (blob !== undefined && !blob.contentType.includes('application/ydoc')) {
  ctx.warn('refusing to load non-ydoc blob as ydoc', { blobId, contentType: blob.contentType })
}

Type guard

function isYdocBlob(blob: { contentType: string } | undefined): blob is { contentType: string } & Record<string, unknown> {
  return blob !== undefined && blob.contentType.includes('application/ydoc')
}

Try / catch

try {
  const ydoc = await loadCollabYdoc(ctx, wsIds, blobId)
} catch (err) {
  // after an 'invalid content type' warning, parse failures mean the bytes are not ydoc —
  // fall back to a backup copy or re-create the document
}

Prevention

When it happens

Trigger: A blobId passed to loadCollabYdoc whose stored blob contentType is not application/ydoc — e.g. the blob was written by an older version, was stored without the correct content type, or the wrong blobId is being resolved.

Common situations: Documents created before ydoc content-type tagging was introduced; data migrated between storage backends losing contentType metadata; upload pipelines writing blobs without setting contentType; lookup bugs passing an unrelated blob id.

Related errors


AI-assisted analysis of hcengineering/platform@63e28dc964 (2026-08-29). Data as JSON: /api/errors/cc2888adea1dea60. Report an issue: GitHub.