A deployment can carry the wallet in its environment, not on a mounted disk
The contract requires the application to serve a wallet file and hand its URL and password to the data layer. Until now the only source was a filesystem path, which no container has: `*.ngw` is gitignored, `COPY . .` brings none, and nothing mounts one -- so a deployed instance served 404 where the contract expects bytes. `FESTIPOD_SHARED_WALLET_FILE_BASE64` carries the file itself. It is 810 bytes, and it is not a secret: by design the application hands it to every user who opens the app, so provisioning persistent storage would be guarding something public. One channel for both values, nothing to mount, and a new host needs only its variables. Precedence is deliberate and one-directional: the path always wins when set, and an unreadable path does NOT fall through to the base64 form. A deployment sets exactly one; both set is a leftover, not a fallback chain. Local development and the test harness only ever set the path, so they are untouched. A malformed value answers 500 and names the variable. Answering 404 would have made "configured wrong" indistinguishable from "not configured at all" -- the confusion this codebase has spent two days removing. Proven by serving the same wallet from each source in turn and comparing: identical size, identical sha256. The first attempt at that proof silently exercised the path branch, because Bun auto-loads `.env` and the variable was already there; the checksums matched for the wrong reason. Caught, cleared, and measured again.
This commit is contained in:
@@ -0,0 +1,7 @@
|
||||
# Doc-debt — tech-stack
|
||||
|
||||
> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
|
||||
> One block = one "big change": `why` + `files` + `verify` (leaves to review).
|
||||
|
||||
## Raw markers (consolidate into blocks, then delete)
|
||||
- TOUCHED src/index.ts @2026-08-17 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
|
||||
Reference in New Issue
Block a user