Skip to content

fix(studio-server): check and render keep their history on a drive without hard links - #7737

Open
miguel-heygen wants to merge 1 commit into
mainfrom
fix/history-lock-drive-without-hard-links
Open

miguel-heygen wants to merge 1 commit into
mainfrom
fix/history-lock-drive-without-hard-links

Conversation

@miguel-heygen

Copy link
Copy Markdown
Collaborator

What

On a drive that cannot make hard links, such as a Google Drive folder on Windows, hyperframes check now records its report and hyperframes render records the render again. Before, both finished their real work and then failed with EISDIR: illegal operation on a directory, link '.hyperframes/video-state-lock/owner.pid-<pid>-<uuid>.tmp' -> '.hyperframes/video-state-lock/owner.pid'.

Why

The project history lock publishes owner.pid with link(), and when the drive cannot hard-link it should fall back to an exclusive write. It decided that from its own list of error codes (ENOTSUP, EOPNOTSUPP, ENOSYS, EPERM, EACCES). That list lacked EISDIR, which Windows returns for link() on such drives (libuv maps ERROR_INVALID_FUNCTION to it). Core's atomic file writes already treated EISDIR and EXDEV as "no hard links", so the same drive worked for file saves and failed for the lock.

Every caller of the lock failed the same way: "Check report was not recorded", "Post-render step recordRenderSuccess failed" and "Render output was not registered".

Related work

None.

How

  • packages/core/src/atomicFile.ts owns the list and exports cannotHardLink(error). The list gains ENOSYS, which only the lock had.
  • packages/studio-server/src/history/ownerLock.ts uses cannotHardLink and drops its own copy, so the two can no longer drift.
  • The other link() callers (the engine's frame cache and the producer's plan) already copy on any link failure; unchanged.

Test plan

  • ownerLock.test.ts: the "takes the lock when linking fails with %s" cases now include EISDIR and EXDEV.
  • fails without the fix: with the two source changes reverted, takes the lock when linking fails with EISDIR and ... with EXDEV fail (2 failed, 22 passed), and atomicFile.test.ts's new ENOSYS case fails (1 failed); with the fix, 24 passed and 40 passed (1 skipped as root, unrelated), 3 runs in a row.
  • tsc --noEmit for packages/core and packages/studio-server, oxlint and oxfmt on the four files: clean.
  • Not run: a real Windows Google Drive folder. The failing code path is exercised through the same link() error.
  • Documentation updated: not needed.
  • Comments follow CONTRIBUTING.md "Comments".

…thout hard links

The history lock had its own list of the errors that mean a drive cannot
hard-link, and it lacked EISDIR, which Windows returns on a Google Drive
folder. Every check report and render record there failed. The lock now
uses core's list, the one owner, which also gains ENOSYS from the lock.
@github-actions

Copy link
Copy Markdown
Contributor

Edit accuracy: accurate 267 (base branch 267), smooth 91 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)

This branch has not been deployed

No deployments
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