Skip to content

token_rotator writes to a read-only log handle; devops_tools no longer surfaces child stderr #770

Description

@gHashTag

Two behaviour notes recorded during the 0.16 migration. Neither was introduced by it; both were preserved deliberately rather than fixed silently under cover of a large change.

1. token_rotator.zig opens its log read-only, then writes to it

logEvent opens with .{} — OpenFileOptions.mode defaults to .read_only — and then writes. The 0.15 original did exactly the same (openFile(log_path, .{}) then writeAll), so this is pre-existing and identical on main.

One-word fix: .{ .mode = .write_only }.

It is called out here because this file holds API tokens, and it is the same file whose 0600 had to be re-applied by hand after CreateFileOptions dropped .mode in 0.16. Both halves of its permission handling deserve one look together.

2. devops_tools.zig no longer inherits child stderr

runTriCmd previously set child.stderr_behavior = .Inherit, so a child's stderr went straight to the terminal. It now goes through tri_proc.run, which pipes and captures both streams — so stderr is captured into result.stderr and freed.

Control flow and stdout handling are unchanged, but the user-visible fallback string "OK (no output -- check stderr)" now points at a stream nobody can see. Either surface result.stderr or reword the message.

Why these are filed rather than fixed

A migration that also changes behaviour is a migration nobody can review. Both were left as they were found, and written down instead — which is the only reason the first one is known at all.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions