Question
The character page is read-only. apps/web/src/app/characters/[region]/[realm]/[name]/page.tsx calls getCurrent, getHistory, and getRun (only when a ?job= is present), and 404s when there is no snapshot and no matching job. The single write path is the homepage form posting to /api/v1/searches.
That much is deliberate: character pages are permanent and crawlable, so a page load must not spend metered upstream work — otherwise a crawler would consume the anonymous rate limit and the shared Blizzard budget.
The gap is that a visitor looking at a stale character page has no way to ask for a fresh refresh from there. They must return to the homepage and paste the Raider.IO URL again, which is unobvious enough that it reads as the page being broken.
To decide:
- Whether the character page gets a refresh control that posts to the existing rate-limited
/api/v1/searches endpoint, reusing the current reservation, freshness, and job-polling behaviour (it already polls ?job=).
- What it shows while a root is inside
FRESHNESS_HOURS, where a search reuses the existing snapshot rather than running. Disabled with the next eligible time, or submit-and-reuse silently?
- Whether the control is visible to crawlers at all, given the reason reads are free.
Raised while debugging searches on test; not a fault in any merged change.
Question
The character page is read-only.
apps/web/src/app/characters/[region]/[realm]/[name]/page.tsxcallsgetCurrent,getHistory, andgetRun(only when a?job=is present), and 404s when there is no snapshot and no matching job. The single write path is the homepage form posting to/api/v1/searches.That much is deliberate: character pages are permanent and crawlable, so a page load must not spend metered upstream work — otherwise a crawler would consume the anonymous rate limit and the shared Blizzard budget.
The gap is that a visitor looking at a stale character page has no way to ask for a fresh refresh from there. They must return to the homepage and paste the Raider.IO URL again, which is unobvious enough that it reads as the page being broken.
To decide:
/api/v1/searchesendpoint, reusing the current reservation, freshness, and job-polling behaviour (it already polls?job=).FRESHNESS_HOURS, where a search reuses the existing snapshot rather than running. Disabled with the next eligible time, or submit-and-reuse silently?Raised while debugging searches on
test; not a fault in any merged change.