Skip to content

server2: do not wait for supplementary KMA inputs - #2865

Draft
hwanjjang wants to merge 2 commits into
masterfrom
feat/2614-kma-optional-arms
Draft

hwanjjang wants to merge 2 commits into
masterfrom
feat/2614-kma-optional-arms

Conversation

@hwanjjang

@hwanjjang hwanjjang commented Nov 6, 2026 •

Copy link
Copy Markdown
Collaborator

Follow-up of #2864 on master. Draft: AK decides on the merge, because a first response may now lack supplementary data that is not held yet.

Why

On 2026-11-06 the EC2 run of #2864 showed first requests on stored data ending at about 3.0 s for both binaries, 3.01 to 3.05 s at the client in six of ten runs. The forecast, observations and air were in by about 2.2 to 2.5 s. The life arm (the UV index walking earlier slots) waited to its 2.7 s bound, and the narrative read after the assembly added 0.1 to 0.3 s. AK approved option 2: once the required information is in, stop waiting for supplementary information such as the UV index or the forecast narrative.

What changes

Under the observed source:

  • Life inputs are supplementary. The required inputs are the grids, RSS, mid forecast, station observations and history, air, and warnings. The life load (UV, pollen, food poisoning, and KASI sunrise and sunset) runs as its own task. Once all required inputs are in, the answer takes the life data this process holds, and KASI sunrise and sunset fall back to the computed values as approved on 2026-11-05. The task goes on: its reads, the acquisitions they lead to and the read-back serve later requests (review OPT-life-continuation). This applies to found towns and to towns outside the list.
  • The narrative is read beside the snapshot. The read starts after prepare, from the request's province. The answer takes it only if the read has ended when the answer is assembled. Otherwise the read continues and fills the 30 s narrative cache.

The required inputs keep their bounds (2.5 s, air 2.7 s). The legacy-path source (S3Source::new) keeps joining the life inputs and waiting for the narrative.

The required inputs and the life arm are counted in one join, each input on the heap. Passing the joined inputs by value overflowed the 2 MiB worker stack in debug builds.

Verification

  • New: with the UV index listing held past the answer, an observed snapshot returns at once (about 0.2 s instead of at 2.5 s) without acquiring. After the release, and with no further request, its life load acquires and publishes. A later snapshot answers the data, with one acquisition in total.
  • New: a ready narrative is in the answer; a never-ending one is not, and the answer comes well before the 2.9 s narrative bound.
  • Full suite, clippy -D warnings, the placement gate and the artifact policy. Mutations of each rule fail their tests.

Not run: an EC2 measurement of this change.

Decisions for AK

  1. Air stays required. The app shows it prominently, and it was in before the observations in the measurements.
  2. A first answer may lack UV, pollen, food poisoning and KASI sunrise and sunset (computed instead), and the narrative, when they are not held yet. Later requests carry them.

🤖 Generated with Claude Code

hwanjjang and others added 2 commits November 6, 2026 17:22
AK (2026-11-06) approved stopping the wait for supplementary information
once the required information is in. Under the observed source the life
inputs (UV, pollen, food poisoning, sunrise and sunset) no longer hold an
answer once the grids, RSS, mid forecast, observations, air and warnings
are in: the answer takes what the process holds and their owned reads and
acquisitions continue. The narrative is read beside the snapshot from the
request's province and attached only when that read has ended. The
legacy-path source keeps its joins.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review of #2865 (OPT-life-continuation): dropping the life load when the
required inputs were in also dropped the acquisitions its first read would
lead to, so nothing acquired them until another request came. The load now
runs as its own task; the answer takes the held life data and the task goes
on to read, acquire and read back. The test holds the UV listing past the
answer and sees the acquisition start and publish with no further request.

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

Copy link
Copy Markdown
Collaborator Author

Cross-provider review (Codex gpt-6.1-sol, high, read-only)

Round 1 on f2842d04: CHANGES_REQUESTED. Round 2 on a0967c52: PASS, all findings resolved.

Required

  • OPT-life-continuation — When the required inputs were in, the life load was dropped, and that also dropped the acquisitions its first S3 read would have started. Nothing acquired UV, pollen or MFDS until another request came. Fixed: the life load runs as its own task, and the answer takes the held data while the task reads, acquires and reads back.

Recommended

  • OPT-life-test-ownership — The test could not tell a continued acquisition from one restarted by later requests. Fixed: the test holds the UV listing past the answer, then sees the acquisition publish with no further request (one acquisition in total). The previous drop-based body fails it.

Reviewer availability: the additional Grok and Gemini reviewers were not launched (permission classifier refusal, recorded for #2863).

🤖 Generated with Claude Code

@hwanjjang

Copy link
Copy Markdown
Collaborator Author

Merge-ready (not merged): head a0967c52 on base d5ba8a09. All 14 CI checks pass, mergeable CLEAN, and the Codex review passed with every finding resolved. Locally: full suite 1,215 passed, release KMA and gateway smokes pass, and five mutation checks fail their named tests. Not run: an EC2 measurement. AK decides on the merge and the two decisions in the description. Merging deploys nothing.

🤖 Generated with Claude Code

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