fix(docker): pre-create node_modules with node ownership for named volume#70
Merged
TortoiseWolfe merged 1 commit intomainfrom May 5, 2026
Merged
Conversation
3 tasks
TortoiseWolfe
force-pushed
the
69/node-modules-volume-permissions
branch
from
3decf85 to
33e7b80
Compare
1 task
TortoiseWolfe
added a commit
that referenced
this pull request
May 5, 2026
…regression hotfix) (#76) Batch 8 (commit 52becd7, PR #74) added a module-level shared-secret cache read-path in getMessageHistory to avoid re-deriving ECDH on every poll tick. Post-merge CI showed a real Firefox/WebKit messaging E2E regression: - Run 25306048649 (main, dd83ac7, pre-batch-8) at 07:14 UTC: all green - Run 25332113434 (main, 0e20fb3, post-batch-8) at 17:04 UTC: firefox-msg failed with messages-not-visible timeouts on real-time-delivery, encrypted-messaging, and message-delete-placeholder specs - Subsequent PR runs reproduced the same pattern, with webkit-msg also failing on the rebased PR #70 branch The cache reuse is symmetric in design (same pattern as sendMessage's cache, which has been there for months) but interacts badly with Firefox/WebKit reload + tab semantics. The cached CryptoKey reference appears to behave differently across these browsers when getCurrentKeys returns a freshly-deserialized key from IndexedDB after a page reload — the invalidation guard `cachedSenderPrivateKey !== currentKeys.privateKey` was likely thrashing or holding a stale reference. Hotfix: getMessageHistory now derives a fresh shared secret per call, matching pre-batch-8 behavior. The cache infrastructure remains in place (sendMessage still uses it as before) — this revert is read-path only. Cost: ~6 ECDH derivations/min under polling — measurable but not user-perceivable. A browser-safe instance-aware cache key can return as a separate change once the Firefox CryptoKey-reference behavior is properly understood. Verification: - pnpm run type-check: clean - pnpm run lint: clean - pnpm test: 3237/3237 pass Refs: #74 (introduced regression), runs 25306048649 (last green), 25332113434 (first red post-batch-8) Co-authored-by: TurtleWolfe <TurtleWolfe@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…lume Docker named volumes inherit permissions from the image directory on first mount. Without pre-creating /app/node_modules as node:node, the volume root stays root:root, causing EACCES on container start when pnpm runs as node and tries to recreate .bin. Latent bug: as long as the volume is reused across up/down cycles, ownership stays correct. Bites only on volume reset (docker volume rm scripthammer_node_modules, docker compose down -v, or first-startup of a fresh-clone fork). Phase 1a (GrimGlow browser fork), Phase 2 (RN ScriptHammer), and Phase 3 (KDG-stack) all hit this on first up. Mirrors the ce0e64d fix that originally landed for .next. The .next fix had been removed during 7bdb86a refactor; this commit restores it alongside the new node_modules treatment so both volumes inherit node ownership on first mount. Tested: - docker compose down && docker volume rm scripthammer_node_modules scripthammer_next_cache && docker compose build && docker compose up -d - Container reaches healthy state, no EACCES in logs - docker run --rm -v scripthammer_node_modules:/v alpine ls -ld /v reports 1000:1000 (was root:root before fix) Closes #69 Refs: ce0e64d, 7bdb86a, ~/repos/TranScripts/Docker/Docker_Edited/nodejs_rocks_in_docker_dockercon2023.md Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
TortoiseWolfe
force-pushed
the
69/node-modules-volume-permissions
branch
from
33e7b80 to
ff81662
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
/app/node_modulesand/app/.nextwithnode:nodeownership in the Dockerfiledevstage so Docker named volumes inherit node ownership on first mount, fixingEACCESon container start when pnpm runs asnodeand tries to recreate.bin.ce0e64dpattern that originally landed for.next. The.nextpre-create had been removed during7bdb86a's refactor; this commit restores it alongside the newnode_modulestreatment.Problem
Latent bug. As long as the
scripthammer_node_modulesvolume is reused acrossup/downcycles, ownership stays correct (set once on first install). It bites only on volume reset (docker volume rm scripthammer_node_modules,docker compose down -v, or first-startup of a fresh-clone fork). Symptom:The container enters a restart loop on exit code 243.
Why this matters for the fork roadmap
Phase 1a (GrimGlow browser fork), Phase 2 (RN ScriptHammer extraction), and Phase 3 (KDG-stack template) all start from a
gh repo createclone followed by a freshdocker compose up— i.e., always a brand-new volume. Every fresh fork will hit this bug on first startup. Fix once at the source.Test plan
Verified locally:
docker compose down && docker volume rm scripthammer_node_modules scripthammer_next_cache && docker compose build && docker compose up -dUp, noRestarting (243))EACCESerrors indocker compose logs scripthammerdocker run --rm -v scripthammer_node_modules:/v alpine ls -ld /vreports1000:1000(wasroot:rootbefore fix)Refs
Closes #69
ce0e64d(.nextnamed volume)7bdb86a(refactor that dropped the.nextpre-create alongside the slowchown -R)~/repos/TranScripts/Docker/Docker_Edited/nodejs_rocks_in_docker_dockercon2023.md🤖 Generated with Claude Code