Skip to content

Navigation Menu

Sign in
Sign up

fix(ci): give the dump its own schedule instead of the scrape's leftovers - #60

Open
Seungpyo1007 wants to merge 1 commit into
main from
fix/dump-refresh-schedule
Open

fix(ci): give the dump its own schedule instead of the scrape's leftovers #60
Seungpyo1007 wants to merge 1 commit into
main from
fix/dump-refresh-schedule

Conversation

@Seungpyo1007

@Seungpyo1007 Seungpyo1007 commented Sep 8, 2026

Copy link
Copy Markdown
Member

Follow-up to #59, which fixed the wrong half of the problem.

#59 got the scrape to finish inside its budget — for the first time in six weeks the run reached Validate, Integrity check and Generate static dump. It then died in the dump:

Enrich benchmarks 06:13 -> 10:33 260 min (on a 200-minute budget)
Generate static dump 10:39 -> 11:36 57 min cut by the job timeout
total 330 min

Two separate faults

1. The budget did not bind. It is only consulted between sources, so a source that starts at minute 199 runs as long as it likes — 260 minutes against a 200-minute budget. Each source is now capped with timeout (40 min), and the budget drops to 150 so the remainder of the pipeline keeps real room.

2. The dump should not be queued behind a live scrape at all. Whenever the scrape runs long, the dump is the step that gets dropped — that is exactly how the published pages drifted from the records (565 of 2,030 gpu pages advertise a stale verified, plus 93 across soc/watch/pda/brand).

dump-refresh.yml already exists for this: it regenerates the dump from current data with no scraping. When it last ran (2026年06月24日) the dump step succeeded — only Create dump-refresh PR failed, on a transient ##[error]Server Error. It has been dispatch-only ever since, so nothing ran it.

It now runs Tuesdays 03:00 UTC, a day after the Monday scrape and ingest, so the published dump is reconciled with data/ every week no matter how the scrape goes. Both workflows also carry timeout-minutes: 330, because a job that hits GitHub's 6h ceiling is reported as cancelled, not failed, and never shows up as broken.

YAML parses; bash -n on the rendered enrich step passes.

Refs #1

...vers
#59 got the scrape to finish, and the run then died in the dump instead:
 Enrich 06:13 -> 10:33 260 min (on a 200-minute budget)
 Dump 10:39 -> 11:36 57 min, cut by the job timeout
 total 330 min
Two things were wrong. The budget is only consulted *between* sources,
so one long source overran it by an hour; each source is now capped at
40 minutes by `timeout`, and the budget drops to 150 so the rest of the
pipeline keeps real room.
But the dump does not belong behind a multi-hour live scrape at all.
Whenever the scrape runs long the dump is what gets dropped, which is
how the published pages drifted away from the records for six weeks.
dump-refresh.yml already regenerates the dump from current data with no
scraping — and when it last ran, the dump step succeeded; only the PR
creation failed on a transient server error. Give it a weekly schedule
(Tuesdays, a day after the Monday jobs) so the published dump is
reconciled with data/ every week regardless of how the scrape goes, and
a job timeout so it can never be silently truncated either.
Refs #1 
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

AltStyle によって変換されたページ (->オリジナル) /