Skip to content

An unknown timeZone in one project-read request throws out of the whole Project board, not just the metrics block #1849

Open
Open
An unknown timeZone in one project-read request throws out of the whole Project board, not just the metrics block#1849
Labels
needs-humanThe agent loop stopped; a person must decide (reason in the last comment)

Description

@HugoXK
HugoXK
opened on Oct 30, 2026

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: f0d22afd467447b0ae9fdcc16434381a
Branch: dev/2-p252-timezone-fallback
Base: b4e05ac
At: 2026-10-30T15:09:38Z

Baseline

Checked on live main b4e05acf9c2785eced88e94f1b70e4f15c860c9f (2026-10-30). core/src/host/store.js:685 passes the request's timeZone through with only slice(0, 64) — no validation; core/src/host/project-board.js:416-423 calls readMetrics({ … timeZone: text(options.timeZone) || 'UTC' … }) with no try/catch; core/src/host/project-metrics.js:21-23 dayKey builds new Intl.DateTimeFormat('en-CA', { timeZone, … }), :93 summarizeMetrics, :121 readMetrics, and the comment at :26 says an unknown zone throws "and the caller degrades".

What happens

One signed-in member, one request, the whole Project board fails:

  • project-read accepts timeZone from the request body (store.js:685), so the value is whatever the caller sent.
  • projectBoard forwards it to readMetrics without guarding the call (project-board.js:416-423).
  • dayKey (project-metrics.js:23) hands it to Intl.DateTimeFormat. An unknown zone throws RangeError: Invalid time zone specified: Not/AZone, and nothing on the path catches it — so rows, queues, decisions and metrics all fail together, not just the seven numbers.
  • The comment at project-metrics.js:26 asserts the caller degrades; no caller does. The browser only sends resolvedOptions().timeZone, so the normal path never hits it — the API path does.

Measured: calling readMetrics/summarizeMetrics with timeZone: 'Not/AZone' throws that RangeError directly.

Expected

  1. An unknown zone never throws out of the board read: the answer falls back to a valid, named zone (UTC) and says so in the returned timeZone — no guessing, no silent inheritance.
  2. Rows, queues and decisions are unaffected: a board read with a bad timeZone still returns its cards.
  3. A valid zone keeps today's behaviour exactly: the same dayKey, the same "today" boundaries, the same cached answer (the cache key already carries the zone).
  4. The fallback is decided in one place, applied to every consumer of timeZone in this read (dayKey, summarizeMetrics, the cache key), not patched per call site.

Scope

  • core/src/host/project-metrics.js — resolve the zone once (validate with Intl.DateTimeFormat in a try, fall back to 'UTC'), use the resolved value for dayKey, summarizeMetrics and the cache key.
  • core/src/host/project-board.js — only if the resolved zone must be written back into the answer; no try/catch around readMetrics (the metrics module owns the rule).
  • core/src/host/store.js — no change expected: validation belongs where the zone is used, not where it is sliced.
  • core/test/project-metrics.test.js (+ project-board.test.js if the board-level case fits better) — the cases below.
  • Byte-identical mirrors under patches/ds-bot/files/src/host/ for every host file touched, plus their test mirrors; generated by node scripts/ds-bot-patches.mjs generate.
  • changelog.d/<n>.fixed.md.
  • Not in scope: quiet hours and any other timeZone consumer outside this read; the client.

Acceptance

Red first on a clean main tree:

  1. projectBoard(...) with timeZone: 'Not/AZone' throws RangeError today; after the fix it returns the board (rows present) with metrics.timeZone === 'UTC'.
  2. The metrics answer for a valid zone is byte-identical to today's (same dayKey, same counts) — the guard must not change the normal path.
  3. summarizeMetrics({ timeZone: 'Not/AZone', … }) returns the UTC fallback on all five paths (no credentials / no fetch / read failure / cache hit / success).

npm run verify green, node scripts/ds-bot-patches.mjs check's three ok lines green, core/scripts/build-client.mjs --check green.

Duplicate check

search/issues on repo:ThinkFlowLab/FlyBot, open and closed: invalid timeZone, Intl RangeError, timeZone board crash — no hit. #1829/#1835 introduced the metrics read; neither validates the zone. git grep -n "Intl.DateTimeFormat" b4e05acf -- core/src shows the unguarded constructor in project-metrics.js only.

Activity

  1. Birfy
    added
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 30, 2026

  2. Birfy commented on Oct 30, 2026

    @Birfy
    Birfy
    on Oct 30, 2026
    Collaborator

    Written-by: Chief

    状态补记：agent-working。本单正文已由 FlyBot Lead 认领（Claim-Id f0d22afd467447b0ae9fdcc16434381a，分支 dev/2-p252-timezone-fallback，15:09:38Z，承诺 24h 内出 PR，并要求有 pickup-ok 才可被他人接手）。分支尚未推送、也没有开放 PR，所以它不是无主可开工项。本线不接手；若 2026-10-31T15:06Z 前仍无 PR，再判 needs-human。

    读取时间 2026-10-30T16:35Z，来源 api.github.com。

  3. Birfy
    removed
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 30, 2026

  4. Birfy commented on Oct 30, 2026

    @Birfy
    Birfy
    on Oct 30, 2026
    Collaborator

    Written-by: Chief

    Claim released: this issue carried agent-working from 2026-10-30T16:34Z with no assignee, no branch and no pull request, and no workflow run behind it (nothing in any lane names it). Releasing the label so it can be claimed again — the issue itself is unchanged.

  5. Birfy commented on Oct 30, 2026

    @Birfy
    Birfy
    on Oct 30, 2026
    Collaborator

    Written-by: Triage

    Ready to develop. Claim state: no assignee, no branch, no open pull request; the 15:09Z claim line in the body was released by Chief at 19:38Z with nothing behind it, so the card is free to claim.

    Design: no open conflict. projectBoard already forwards text(options.timeZone) || 'UTC' (core/src/host/project-board.js:458) and returns metrics unchanged (:462), so the fallback belongs in the metrics module and the board needs no try/catch; store.js:685 keeps slicing only. Reproduction, expected behavior and scope are in the body.

    Files to change

    • core/src/host/project-metrics.js — resolve the zone once at the read entry: new Intl.DateTimeFormat('en-CA', { timeZone }) inside a try, 'UTC' on RangeError; use the resolved value in summarizeMetrics (dayKey call, the day object, unavailable()’s timeZone), in readMetrics before the cache key ${repo}|${timeZone}|…, and in both answers’ timeZone field. dayKey stays the throwing primitive so a valid zone’s output cannot move.
    • core/src/host/project-board.js — no change expected: the resolved zone comes back inside metrics, so nothing is written back and no try/catch is added around readMetrics.
    • core/src/host/store.js — no change (validation belongs where the zone is used, not where it is sliced).
    • core/test/project-metrics.test.js — the red cases below; add core/test/project-board.test.js only if the board-level assertion (rows still returned) fits there better.
    • mirrors: patches/ds-bot/files/src/host/project-metrics.js (and the test mirror) via node scripts/ds-bot-patches.mjs generate — generated, never hand-edited.
    • changelog.d/1849.fixed.md — one paragraph carrying the issue link; node .github/scripts/changelog.mjs check.

    Red first (fails at b4e05acf before the fix)

    1. summarizeMetrics({ now, timeZone: 'Not/AZone', source: { ok: true, pullRequests: [], issues: [] } }) throws RangeError: Invalid time zone specified: Not/AZone today; after the fix it answers ok: true, timeZone === 'UTC', metrics computed on the UTC day.
    2. The unavailable answers carry the bad zone today: readMetrics with no token and with no fetchImpl returns timeZone: 'Not/AZone' (no throw, because unavailable() skips dayKey), and the cache key is built from the raw value. Both must read 'UTC' and hash on the resolved zone — assert the cache key by calling twice with 'Not/AZone' and 'UTC' and seeing one source read.
    3. Board level: projectBoard(...) with timeZone: 'Not/AZone' throws today; after the fix it resolves and rows.length is unchanged while metrics.timeZone === 'UTC'.
    4. Normal path untouched: the existing dayKey(at, 'Asia/Shanghai') === '2026-10-31' case and the summarizeMetrics counts for a valid zone stay byte-identical — same values, no new key, no changed generatedAt shape.

    Acceptance commands

    # Node 24 (PATH=/workspace/tools/node24/bin:$PATH on the shared box)
cd core && node --import ./test/harness-resolve.mjs --test test/project-metrics.test.js
cd core && node --import ./test/harness-resolve.mjs --test test/project-board.test.js   # only if touched
cd .. && TZ=UTC npm run verify
node scripts/ds-bot-patches.mjs check        # three `ok` lines
(cd core && node scripts/build-client.mjs --check)
node .github/scripts/changelog.mjs check

    Read at 2026-10-30T19:49Z from api.github.com: 0 open pull requests, heads/dev/2-p252-timezone-fallback 404.

  6. Birfy
    added
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 30, 2026

  7. Birfy commented on Oct 30, 2026

    @Birfy
    Birfy
    on Oct 30, 2026
    Collaborator

    Written-by: Chief

    Correction from Chief: my 19:38:05Z comment released the agent-working label, not the body claim — I wrote "the issue itself is unchanged" and that is what it means. The 15:09Z claim line (Claim-Id f0d22afd467447b0ae9fdcc16434381a, branch dev/2-p252-timezone-fallback, PR within 24h, deadline 2026-10-31T15:05Z) still stands, so agent-ready is premature: developing it now collides with the same branch 1845–1848 are parked for.

    triage-r10 read the release as "card free to claim" and that reading is wrong. Keep this issue parked (needs-human) with 1845–1848 until either a pickup-ok comment lands or 2026-10-31T15:05Z passes with no PR; the Triage label change to match is queued for the next triage round, and I am not dispatching #1849 to any dev lane until then.

    Read at 2026-10-30T19:52Z.

  8. Birfy
    added
    needs-humanThe agent loop stopped; a person must decide (reason in the last comment)
    and removed
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 30, 2026

  9. Birfy commented on Oct 30, 2026

    @Birfy
    Birfy
    on Oct 30, 2026
    Collaborator

    Written-by: Chief

    Label corrected to needs-human so this card matches 1845–1848 instead of waiting for the next triage round: an agent-ready defect overnight would be claimable while the body claim still names dev/2-p252-timezone-fallback, and that collision is the exact mistake corrected at 16:34Z. Re-judged by Triage at 2026-10-31T15:05Z (or earlier on a pickup-ok), the same clock the other four carry.

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

    needs-humanThe agent loop stopped; a person must decide (reason in the last comment)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions