Activity

1. wladpaiva

   added

   bugSomething isn't workingSomething isn't working

   on May 12, 2026
2. theoephraim commented on May 13, 2026

   

   theoephraim

   on May 13, 2026

   Member

   More actions

   Thanks for the report! We use the regular deploy command so didn’t catch this. Will get it fixed shortly.

   👍React with 👍1Reacted by Wlad Paiva
3. theoephraim

   assigned

   Copilot

   and

   theoephraim

   on May 13, 2026
4. Copilot

   linked a pull request that will close this issuecloudflare: omit unsupported `--keep-vars` for `wrangler versions upload` #702on May 13, 2026
5. wladpaiva commented on May 13, 2026

   

   wladpaiva

   on May 13, 2026

   Author

   More actions

   thanks @theoephraim .

   I patched this problem but I got to another problem when running varlock-wrangler versions upload on wrangler@4.9.1.

   Wrangler rejects Varlock’s generated --secrets-file.

   Varlock was writing the secrets temp file as JSON:

   {"BETTER_AUTH_SECRET":"...","TURSO_AUTH_TOKEN":"..."}

   But Wrangler expects --secrets-file to be dotenv-style KEY=VALUE content, like:

   BETTER_AUTH_SECRET="..."
   TURSO_AUTH_TOKEN="..."
   

   This is my patch but after seeing your pr I'm pretty sure I'm breaking something else

   diff --git a/dist/varlock-wrangler.js b/dist/varlock-wrangler.js
   index 1e58d423aa5c00abb303035e7e18623bb6fc362d..525fc8e19fe4f04a6b48a6d5f697c3b768b25374 100644
   --- a/dist/varlock-wrangler.js
   +++ b/dist/varlock-wrangler.js
   @@ -211,6 +211,6 @@ async function handleDeploy(args) {
      addVarlockEnvToRecord(secretsObj, loaded.json);
      const tmp = createServingTempFile("varlock-secrets");
   -  const content = JSON.stringify(secretsObj);
   +  const content = Object.entries(secretsObj).map(([key, value]) => formatEnvLine(key, value)).join("\n");
      debug("deploy: starting FIFO serve");
      const handle = tmp.startServing(() => content);
      process.on("SIGINT", () => {
   @@ -232,7 +232,7 @@ async function handleDeploy(args) {
      let exitCode = process.exitCode ?? 0;
      try {
        debug("deploy: spawning wrangler");
   -    exitCode = await spawnWrangler([...args, ...varFlags, "--secrets-file", tmp.filePath, "--keep-vars=false"]);
   +    exitCode = await spawnWrangler([...args, ...varFlags, "--secrets-file", tmp.filePath]);
        debug("deploy: wrangler exited with code", exitCode);
      } finally {
        debug("deploy: cleaning up");
   
6. theoephraim commented on May 13, 2026

   

   theoephraim

   on May 13, 2026

   Member

   More actions

   

   Unless they changed it and forgot to update the docs, then json is definitely allowed. What was the error you were seeing?
7. wladpaiva commented on May 13, 2026

   

   wladpaiva

   on May 13, 2026

   Author

   More actions

   Weird, I got a message saying that it accepts both file but it failed to accepts the one generated. But now I tried it again and it did not fail

   ¯_(ツ)_/¯

   I guess that's it then.. Removing the keep-vars is the only thing needed
8. garron commented on May 13, 2026

   

   garron

   on May 13, 2026

   More actions

   I had a similar intermittent/non-reproducible issue passing secrets. In case it helps, here was what my LLM drafted for me as a bug report after troubleshooting, although I haven't done an investigation myself:

   varlock-wrangler deploy intermittently produces invalid --secrets-file input when served via FIFO

   Summary

   We hit a production deploy failure where Wrangler reported:

   ✘ [ERROR] The contents of "/tmp/.../varlock-secrets-..." is not valid.
   

   The --secrets-file path was created by @varlock/cloudflare-integration's varlock-wrangler, which serves secrets to Wrangler through a named pipe (FIFO).

   After investigation, we do not think our generated secrets object is malformed JSON. The stronger current hypothesis is that Wrangler is sometimes reading incomplete / empty / otherwise corrupted bytes from the FIFO-backed --secrets-file path.

   Versions

   Observed in:

   • @varlock/cloudflare-integration 1.1.1
   • wrangler 4.90.0 / 4.90.1
   • Bun workspace / Linux CI

   Observed behavior

   Production deploy logs showed Wrangler printing:

   ✘ [ERROR] The contents of "/tmp/.../varlock-secrets-..." is not valid.
   

   Wrangler's own source says this error is raised when the --secrets-file contents are not valid JSON / dotenv input:

   throw new UserError(`The contents of "${input}" is not valid.`)

   and for JSON input it additionally expects a JSON object whose values are all strings.

   Why we think the payload itself is probably valid

   We added instrumentation around our deploy path and inspected the generated secrets payload before Wrangler reads it.

   1. varlock-wrangler constructs JSON from a plain object of string values

   In dist/varlock-wrangler.js, deploy does this:

   • resolve config via varlock load --format json-full --compact
   • build secretsObj
   • coerce every secret value to a string
   • JSON.stringify(secretsObj)
   • serve that JSON through a FIFO path passed to Wrangler via --secrets-file

   So the intended payload shape is always:

   • a JSON object
   • all values strings

   2. We captured the payload shape for the failing app

   For our Worker, the generated secrets payload was small and simple. The top-level keys were only:

   • JWT_PRIVATE_KEY
   • __VARLOCK_ENV

   In local repros, the payload was roughly ~1.3 KB and did not require chunking.

   3. The same content works when passed to Wrangler outside the FIFO path

   We tested Wrangler directly with:

   • a regular JSON secrets file
   • multiline secrets
   • realistic PEM content
   • deploy --dry-run

   Wrangler accepted it.

   We also tested varlock-wrangler locally against the same app/workspace and could not reproduce the invalid-content error consistently.

   Additional evidence

   We originally suspected malformed repo-specific content, but ruled out several likely causes:

   • not caused by __VARLOCK_ENV_* chunking in our app payload (payload was too small to chunk)
   • not caused by multiline PEM content alone
   • not caused by unresolved literal infisical() values alone
   • not caused by generic Wrangler incompatibility with --secrets-file

   That leaves the FIFO transport path as the strongest remaining suspect.

   Likely failure mode

   varlock-wrangler currently uses a named pipe server for deploy secrets:

   • mkfifo
   • background Node process repeatedly writeFileSync()s the FIFO contents
   • Wrangler reads the FIFO path via --secrets-file

   The most plausible remaining explanation is that, in some environments / timing windows, Wrangler reads:

   • an empty payload
   • a partial payload
   • or otherwise invalid bytes

   from the FIFO-backed path.

   Suggested fixes

   Best upstream fix

   For one-shot deploys, avoid FIFO serving entirely.

   Instead:

   1. write the secrets JSON to a secure temporary file with 0600 permissions
   2. pass that normal file path to Wrangler via --secrets-file
   3. delete the temp file after Wrangler exits

   This is much simpler than a FIFO server and should avoid timing/read issues.
9. theoephraim

   closed this as completedin #702on May 13, 2026
10. theoephraim commented on May 14, 2026

    

    theoephraim

    on May 14, 2026

    Member

    More actions

    @garron - thanks for that! The FIFO helps keep things out of plaintext. But definitely needs to be reliable. Will dig in a bit and see what we can do.

    How often are you seeing issues like that?