Skip to content

fix(lint): don't look for audio on another computer's share - #7572

Merged
jrusso1020 merged 1 commit into
mainfrom
fix/project-symlink-containment
Nov 11, 2026
Merged

jrusso1020 merged 1 commit into
mainfrom
fix/project-symlink-containment

Conversation

@jrusso1020

Copy link
Copy Markdown
Collaborator

Lint no longer looks on disk for an <audio src> that names a share on another computer (\\host\share\..., //host/share/...). On Windows that lookup connects to the host, and Studio runs lint as soon as a project opens.

Claude Opus 5.5

What

The audio_src_not_found check skips a src whose root is a network share other than the project's own. It neither looks for that file nor reports it.

Why

The check passed every <audio src> to resolveProjectRelativeSrc, which calls existsSync on any absolute path. On Windows, checking whether \\host\share\x.wav exists opens an SMB connection to host as the signed-in user. Studio runs lint automatically when a project opens, so just opening a project made that connection. #7534 already stopped the other lint rules, the compile probes and the Studio media scan from looking at another computer's share. This is the one lint path that still did.

Related work

Refs #7534 (same network-root rule, namesAnotherNetworkRoot). #7386 also edits packages/lint/src/project.ts, in a different function (audio overlap hint). #3759 (draft) edits packages/parsers/src/assetResolution.ts, in a different function.

How

  • packages/parsers/src/assetResolution.ts: a new srcOnAnotherNetworkRoot(projectDir, src) cleans the src as the resolver does (query and fragment, file: URL) and returns namesAnotherNetworkRoot for an absolute path. It touches no file.
  • packages/lint/src/project.ts: lintAudioSrcNotFound skips such a src before it resolves the path or checks the #/? file-name hint.

What users see:

  • Project files, local absolute paths (C:\media\voice.wav), and audio on the share the project itself lives on are checked exactly as before.
  • Audio on another computer's share is no longer reported by lint, whether or not it exists. Nothing new is reported for a valid file. The render path is unchanged, so it still reads such a file and still names it when it is missing.
  • On macOS and Linux nothing changes. There, //host/share is a local path, and namesAnotherNetworkRoot is false for it.

The render and check still resolve absolute and UNC media sources, because rendering them is supported (#4172, #7534). This PR does not change that.

Test plan

  • Unit tests added/updated
    • assetResolution.win32.test.ts uses Windows path rules and a recording existsSync. \\host\share, //host/share, /\host\share and a src with ?v=2 count as another share, and none of them touches the disk. Drive-letter, relative and root-absolute srcs, and a src on the project's own share, do not count.
    • lint/src/project.networkRoot.test.ts: the lint never resolves an <audio> src on another share and doesn't report it. A missing project audio file is still resolved and reported.
    • Both tests fail with the fix reverted. Reverting the lint continue fails the lint test (1 of 2), and making the helper return false fails the Windows test (4 of 44).
  • parsers suite 1501 passed, lint suite 1307 passed. Typecheck (parsers, lint), oxlint, oxfmt, fallow audit and the comment ratchet are clean.
  • Manual testing: not run on real Windows. Windows path rules are tested with path.win32.
  • Comments follow CONTRIBUTING.md "Comments"

— Rames Jusso

🤖 Generated with Claude Code

The audio-missing check resolved every <audio src> on disk, including a
src naming a share on another host (\\host\share, //host/share). On
Windows that lookup opens a connection to that host, and Studio runs lint
as soon as a project opens. The check now skips a src whose root is a
network share other than the project's own, as the other lint rules
already do. Media on the project's own share, local absolute paths and
project files are checked as before; the render still reports a file it
cannot find.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

Edit accuracy: accurate 267 (base branch 267), smooth 105 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

Unstable (1)

  • seqab-none-pct-r0-root-z100: tracking 0.05, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true

@heygengenesis heygengenesis Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verdict: APPROVE · 0 blocker · 0 important · 0 nits · head 109bf1cd

Scope
  • Read all 4 files. The skip cleans the src exactly as resolveProjectRelativeSrc does, and it runs on the same rootRelative. The resolver's only lookup of an absolute path is existsSync(cleanSrc), and the skip covers it. The other candidates are joined under the project, so they stay local.
  • Checked with a path.win32 probe that records every disk lookup. I tried percent-encoded %5C%5Chost…, \\?\UNC\…, \\.\pipe, ..\ climbs, a project on \\nas\films, and a different share on the same host. None of them looked up another computer's share. \\?\ paths get cut at the ? before any lookup, both before and after this PR.
  • Locally: parsers win32 44/44 and lint 2/2 pass. Reverting the continue fails 1 of 2, and making the helper return false fails 4 of 44, which matches the body.
  • CI: every required check at this head passed (Skills: manifest in sync skipped by path filter).

— Genesis

@jrusso1020
jrusso1020 added this pull request to the merge queue Nov 11, 2026
Merged via the queue into main with commit 7ba8f85 Nov 11, 2026
82 checks passed
@jrusso1020
jrusso1020 deleted the fix/project-symlink-containment branch November 11, 2026 23:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant