Skip to content

server2: answer a held minute page while the next one arrives - #2868

Draft
hwanjjang wants to merge 1 commit into
masterfrom
feat/2614-kma-minute-page
Draft

hwanjjang wants to merge 1 commit into
masterfrom
feat/2614-kma-minute-page

Conversation

@hwanjjang

Copy link
Copy Markdown
Collaborator

Summary

On EC2 (2026-11-07, 01:29-03:12 KST) one or two requests of most rounds took 2.4-3.6 s. Each found the newest KMA AWS minute page (nph-aws_txt_min, about 470 KB of EUC-KR HTML) more than 2 minutes old, started the next page and waited for it; the page took 2.1-2.6 s, at the observed 2.5 s bound, so the request usually still answered the previous page. Legacy collected the page every 2 minutes in the background and answered from the stored page.

While a page of the last 20 minutes (the readers' reach) is held, the request now starts the owned acquisition detached and answers with the held page; the next page serves later requests. Without a held page (a cold process with nothing stored) the request waits as before. The cadence (one page per 2 minutes, whatever the outcome) is unchanged.

Changes

  • observe.rs ensure_minute: MINUTE_HELD_MS (20 minutes); a held page spawns the owned acquisition and returns nothing to wait for.
  • Architecture document: the request-time acquisition table.
  • Records: intent/, specs/, plans/issue-2614-kma-minute-page.md; declaration server2/config/tasks/KMA-MINUTE-PAGE.json.

Verification

  • New test a_held_minute_page_answers_while_the_next_one_is_acquired: a restarted process with the stored 10:49 page, asked at 10:53 with a provider that takes 3 s, answers within 1.5 s with the held rows, and the next page is acquired. 3 of 3 mutations caught; M1 (the request waits, the behavior before this change) is the Red evidence.
  • Full cargo test --locked --workspace 1,214 passed, 0 failed, 7 ignored; cargo fmt --check, cargo clippy -D warnings, placement gate and artifact policy pass.

Decision for AK

  • A request that arrives when the next page is due answers the held page, up to about 4 minutes old (2-minute cadence plus the page's own lag), instead of waiting up to 2.5 s for a page it usually missed anyway.

Not in this change: a scheduled fetch without requests, the hourly and city pages, and the other fixes of the EC2 report (#2866 restart reads, #2867 AirKorea refresh).

🤖 Generated with Claude Code

The KMA AWS minute page (about 470 KB for every station) took 2.1-2.6 s
to arrive on EC2, at the observed 2.5 s bound. A request that found the
newest page more than 2 minutes old started the next page and waited
for it, and usually still answered the previous page.

While a page of the last 20 minutes (the readers' reach) is held, the
request now starts the owned acquisition detached and answers with the
held page; the next page serves later requests. Without a held page the
request waits as before. The cadence (one page per 2 minutes, whatever
the outcome) is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@hwanjjang

hwanjjang commented Nov 6, 2026 •

Copy link
Copy Markdown
Collaborator Author

Cross-provider review (Codex gpt-6.1-sol, high): PASS at 7ffae72.

Recommended

  • MP-refresh-test (check that a page fetched in the background reaches the next answer): not adopted. The change only stops the request from waiting; the path by which an acquired page is stored, marked dirty and folded for later requests is unchanged by this PR.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant