On a Docker Desktop / virtiofs bind mount of a macOS host, mkdir, writeFile, and symlink return success but lstat/realpath/existsSync on the path they just created report ENOENT for the next 1-2ms. open, read, and write on that path work immediately -- the lookup path lags, not the data. Measured visibility after mkdir: 0/10 at 0ms, 9/10 at 1ms, 10/10 at 2ms. Sandboxed agent environments commonly mount the workspace this way.
deepsec assumed POSIX durability-on-return in a few places, so init failed with "ENOENT: no such file or directory, mkdir 'data/'" -- recursive mkdir creates data/, then cannot see it when it looks up the child.
Adds settleFs, existsSettled, and mkdirSettled: a flat 100ms wait after creating a path, tunable via DEEPSEC_FS_SETTLE_MS (0 opts out). Not a poll-until-visible loop -- this is a handful of call sites on one code path, and the simplicity is worth more than the milliseconds. mkdirSettled retries the mkdir once on ENOENT, since that is where the failure surfaces; any other errno is a real error and is rethrown untouched.
Used only where this process just created the path: ensureProject's data dir, the init workspace dir, init-project's data dir, and the post-install node_modules probe. Resume detection, atomic-file temp cleanup, and the mkdir lock primitive are left alone -- those paths were created by an earlier process or are legitimately absent most of the time, where waiting is pure cost.
Refs #159
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Activity
7
cramforce2mo agoClanker feedback: • Found one blocking issue:
- [P1] Settling occurs before installation, not before the post-install probe. existsSettled (https://github.com/vercel-labs/deepsec/blob/98cae0402975a5fe1a2971da3c85e0f621bfb2f9/packages/deepsec/src/setup/coordinator.ts#L409-L415) only runs when an install checkpoint already exists. On fresh initialization it is skipped, then ensureWorkspaceInstall (https://github.com/vercel-labs/deepsec/blob/98cae0402975a5fe1a2971da3c85e0f621bfb2f9/packages/deepsec/src/setup/install.ts#L128-L129) immediately probes the newly created node_modules using raw existsSync. The same metadata lag can therefore still report “workspace is unusable.” Settle immediately after the installer exits, before probeWorkspaceInstall, and add a regression test for that sequence.
The new core tests pass locally, but they don’t exercise this installer path. The PR is currently blocked by unauthorized Vercel deployment checks; Socket and Vercel Agent Review pass. PR #160 (https://github.com/vercel-labs/deepsec/pull/160)
ezufelt2mo agoClanker feedback: • Found one blocking issue:
- [P1] Settling occurs before installation, not before the post-install probe. existsSettled (https://github.com/vercel-labs/deepsec/blob/98cae0402975a5fe1a2971da3c85e0f621bfb2f9/packages/deepsec/src/setup/coordinator.ts#L409-L415 ) only runs when an install checkpoint already exists. On fresh initialization it is skipped, then ensureWorkspaceInstall (https://github.com/vercel-labs/deepsec/blob/98cae0402975a5fe1a2971da3c85e0f621bfb2f9/packages/deepsec/src/setup/install.ts#L128-L129 ) immediately probes the newly created node_modules using raw existsSync. The same metadata lag can therefore still report “workspace is unusable.” Settle immediately after the installer exits, before probeWorkspaceInstall, and add a regression test for that sequence.
The new core tests pass locally, but they don’t exercise this installer path. The PR is currently blocked by unauthorized Vercel deployment checks; Socket and Vercel Agent Review pass. PR #160 (#160)
Thanks for the feedback, I pushed a new commit.
@ezufelt is attempting to deploy a commit to the Vercel Labs Team on Vercel.
A member of the Team first needs to authorize it.