fix: three fixes that only appeared to work — redaction, timezone, --watch - #119
Merged
Merged
Conversation
…watch
Each of these shipped with a green test that asserted the wrong thing.
The API redacted secrets by name, and the exemption for frontend-published
variables (VITE_, NEXT_PUBLIC_, MIX_, REACT_APP_, …) returned BEFORE the
secret-word check — the opposite of what the comment directly above it claimed.
GET /api/v1/processes/{name} therefore served VITE_DB_PASSWORD,
NEXT_PUBLIC_API_SECRET and MIX_PUSHER_APP_SECRET in cleartext. Naming a password
VITE_DB_PASSWORD is a mistake; publishing its value is not the way to point that
out. The exemption now yields to an unambiguous secret word — password, secret,
token, private_key, passphrase, salt — while still ignoring the merely key-ish
ones a genuinely publishable key carries, so NEXT_PUBLIC_API_KEY, VITE_API_URL
and STRIPE_PUBLISHABLE_KEY stay readable.
schedule_timezone never took effect. NewScheduledJobWithOptions built the
CRON_TZ-prefixed spec correctly and stored the parsed schedule on the job — and
then the scheduler registered the RAW expression with cron.AddJob, which
re-parsed it in the cron instance's own default location. The parsed schedule
was computed, stored, and used nowhere. A job configured for
America/New_York fired at 03:00 UTC instead of 08:00. The existing test was
green because it asserted on that dead field; the new one goes through the
Scheduler and reads back the entry the cron library will actually fire.
--watch was a no-op for a symlinked config on Linux. filepath.Abs does not
resolve symlinks, so the directory watch landed on the LINK's directory, where
nothing ever changes — the shape you get from /etc/cbox-init/cbox-init.yaml
pointing into a mounted volume, or from a Kubernetes ConfigMap's ..data
indirection. Both directories are now watched, since which one sees the event
depends on the shape: a plain symlink changes at the target, while a ConfigMap
update swaps the ..data link beside the link itself. macOS's kqueue backend
follows the symlink and hid this entirely, so the test asserts the watch list
structurally as well as behaviourally.
sylvesterdamgaard
force-pushed
the
fix/redaction-timezone-symlink
branch
from
August 27, 2026 12:14
10242b0 to
e963a67
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
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.
Each of these shipped with a green test that asserted the wrong thing.
The API redacted secrets by name, and the exemption for frontend-published
variables (VITE_, NEXT_PUBLIC_, MIX_, REACT_APP_, …) returned BEFORE the
secret-word check — the opposite of what the comment directly above it claimed.
GET /api/v1/processes/{name} therefore served VITE_DB_PASSWORD,
NEXT_PUBLIC_API_SECRET and MIX_PUSHER_APP_SECRET in cleartext. Naming a password
VITE_DB_PASSWORD is a mistake; publishing its value is not the way to point that
out. The exemption now yields to an unambiguous secret word — password, secret,
token, private_key, passphrase, salt — while still ignoring the merely key-ish
ones a genuinely publishable key carries, so NEXT_PUBLIC_API_KEY, VITE_API_URL
and STRIPE_PUBLISHABLE_KEY stay readable.
schedule_timezone never took effect. NewScheduledJobWithOptions built the
CRON_TZ-prefixed spec correctly and stored the parsed schedule on the job — and
then the scheduler registered the RAW expression with cron.AddJob, which
re-parsed it in the cron instance's own default location. The parsed schedule
was computed, stored, and used nowhere. A job configured for
America/New_York fired at 03:00 UTC instead of 08:00. The existing test was
green because it asserted on that dead field; the new one goes through the
Scheduler and reads back the entry the cron library will actually fire.
--watch was a no-op for a symlinked config on Linux. filepath.Abs does not
resolve symlinks, so the directory watch landed on the LINK's directory, where
nothing ever changes — the shape you get from /etc/cbox-init/cbox-init.yaml
pointing into a mounted volume, or from a Kubernetes ConfigMap's ..data
indirection. Both directories are now watched, since which one sees the event
depends on the shape: a plain symlink changes at the target, while a ConfigMap
update swaps the ..data link beside the link itself. macOS's kqueue backend
follows the symlink and hid this entirely, so the test asserts the watch list
structurally as well as behaviourally.