fix(sandbox): keep the default isolation posture off the dev log - #3711
Conversation
A fresh `veryfront dev` printed the worker isolation posture at INFO on the
first request, making an internal capability resolution the only output a
successful request produced:
● Worker isolation posture resolved
master=false effectiveSurfaces=0 workerIsolationApi=false ...
Nothing there is actionable for a developer who configured no isolation, and
it is the first thing a new project sees after "Ready".
Report the posture at DEBUG when no surface is in force, and keep INFO for the
case an operator actually configured something. The two misconfiguration
warnings are untouched — those are genuinely actionable.
Found while dogfooding the documented quickstart against published v0.1.1237.
📦 Client bundle boundary
A server module in a client graph aborts hydration in the browser. New leaks fail CI; known leaks are tracked in |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe worker pool now logs inactive isolation postures at DEBUG and active postures at INFO. Tests cover both logging levels. ChangesIsolation posture logging
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This narrowly changes an unconfigured isolation status message from info to debug while preserving informational logging for configured isolation and actionable warnings; no merge-blocking risk remains beyond normal checks and review. Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Found while dogfooding the documented quickstart against published v0.1.1237.
What a developer sees today
A fresh
npm create veryfrontproject, first request toveryfront dev:That posture line is the only thing a successful request prints, and it is the first
thing a new project shows after
Ready. Nothing in it is actionable for someone whoconfigured no isolation at all.
Change
Report the posture at
DEBUGwhen no surface is in force; keepINFOonce an operatorhas actually configured something. The two misconfiguration
warnbranches areuntouched — those are genuinely actionable.
Tests
Two regression tests in
src/security/sandbox/isolation-posture.test.tspin both sidesof the boundary: the unconfigured posture must not log at
info, and an in-force posturemust still reach
info. The first fails onmain(infovsdebug); the second passesbefore and after, so it guards against over-correcting into silence.
src/security/sandbox/— 40 passed, 0 failed.Summary by CodeRabbit
Bug Fixes
Tests