fix(ui+http): timezone validator + system-configs 404 noise#1173
Open
vanducng wants to merge 1 commit into
Open
fix(ui+http): timezone validator + system-configs 404 noise#1173vanducng wants to merge 1 commit into
vanducng wants to merge 1 commit into
Conversation
Two small quick-fixes:
1. Timezone save rejected with "Invalid timezone" toast even when the
user picked a valid IANA name from the dropdown. Root cause:
isValidIanaTimezone built a Set from Intl.supportedValuesOf() then
canonicalized each name via Intl.DateTimeFormat(...).resolvedOptions().
Across browser/OS combos this drops or remaps some names (e.g.
Asia/Saigon ↔ Asia/Ho_Chi_Minh varies — only one ends up in the
rebuilt Set, depending on the browser's tz database revision).
When the user's stored value happens to be the absent form, save
fails. Replace with direct Intl.DateTimeFormat try/catch — the
canonical IANA validation path; accepts every name the browser
understands, deprecated aliases included.
2. /v1/system-configs/{key} returned 404 for missing alert keys. The
frontend (background-error-banner.tsx) already handles this silently
via .catch — but Chrome logs the 404 to the console regardless.
The polled alert key (alert.background.provider_error) legitimately
doesn't exist most of the time, so the console fills with "Failed
to load resource" entries. Return 200 with empty value instead —
"missing" == "empty" matches settings-store semantics, and the
frontend's existing `if (res.value)` guard already handles both.
Contributor
|
Backlog review: merge-candidate. The timezone validator change uses Intl directly, which handles canonical/deprecated IANA aliases better than the Set-based check, and the system-config missing-key behavior is intentionally fail-soft. go and web checks are passing. |
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
Two small quick-fixes that surfaced together on a fork dashboard but apply identically to upstream/dev (both files unchanged from upstream).
1. Timezone save rejected with "Invalid timezone"
Saving a cron job with `Asia/Ho_Chi_Minh` (or any IANA name picked from the dropdown) failed validator and showed an "Invalid timezone" toast.
Root cause: `isValidIanaTimezone` (in `ui/web/src/lib/timezone-utils.ts`) built a `Set` from `Intl.supportedValuesOf("timeZone")` then canonicalized each name via `new Intl.DateTimeFormat(...).resolvedOptions().timeZone`. Across browser/OS combos this drops or remaps some names — e.g. on Chrome 110+ `Asia/Saigon` canonicalizes to `Asia/Ho_Chi_Minh` but on older Safari/Firefox it stays `Asia/Saigon`. When the user's stored value happens to be the absent form, save fails despite the value being a valid IANA name.
Fix: validate via direct `Intl.DateTimeFormat(...)` try/catch. That's the canonical IANA validation path — accepts every name the browser's tz database understands, deprecated aliases included.
2. `/v1/system-configs/{key}` 404 console spam
`background-error-banner.tsx` polls `/v1/system-configs/alert.background.provider_error` to recover alert state after page refresh. When no alert exists (the common case), backend returned 404. The frontend's `.catch()` handled it semantically — but Chrome still logs "Failed to load resource" for every 404. Devtools console fills with hundreds of these entries.
Fix: `handleGet` returns 200 with empty `value` for missing keys. Settings-store "missing" == "empty" is the natural semantics here; the frontend's existing `if (res.value)` guard already handles both shapes. No behavior change for other callers.
Files changed
Test plan
Notes
Tested in production on a downstream fork (dataplanelabs/goclaw v3.23.11) since 2026-05-25. Both fixes resolved the reported user-visible issues; no regressions observed across the trace/cron/alert paths.