Skip to content

fix(usj): decouple wait-time and show-list fetches in live data#181

Open
cubehouse wants to merge 1 commit into
mainfrom
fix/usj-live-data-decouple
Open

fix(usj): decouple wait-time and show-list fetches in live data#181
cubehouse wants to merge 1 commit into
mainfrom
fix/usj-live-data-decouple

Conversation

@cubehouse
Copy link
Copy Markdown
Member

Summary

Targeted hardening of USJ's buildLiveData() to address a multi-hour live-data staleness pattern.

Previously both CDN fetches (wait-time-attraction-list.json and show-list.json) ran in a single Promise.all. If either rejected — Akamai blip, DNS hiccup, transient 503 — the entire emission threw, the collector logged "Failed to fetch live data" and skipped the write. With getWaitTimeData cached only 60s and the collector polling on updateLoopMinutes, even a brief one-sided outage could compound into a long staleness gap if both endpoints didn't recover in the same window.

Changes

  • Promise.allPromise.allSettled
  • Emit live data from whichever fetch(es) succeeded
  • Console-log which side failed (so the next prod incident names the endpoint)
  • Still throw when both fail, so the collector skips the write rather than emitting empty live data (which would mark every attraction CLOSED via the wiki's implicit-closed semantics — worse than staying stale)

Out of scope

The /Venues/.../Hours schedule endpoint is also broken (401 — auth on mobile-service.usj.co.jp has moved to a dynamic-token handshake the collector doesn't speak yet). User flagged that schedules may have moved to the website entirely (would need scraping), so deferred to a separate effort.

Verified

  • npm run build clean
  • npm test 1086/1086 pass
  • npm run dev -- universalstudiosjapan → 104 entities, 42 live data entries — same as before this change in the happy path

Test plan

  • Wait for next observed staleness incident; confirm prod logs now name which endpoint failed
  • If only one side is failing, confirm partial live data is still being written to the wiki

buildLiveData() previously ran both CDN fetches in Promise.all, so a single
endpoint failing rejected the whole live-data emission. The collector
logged "Failed to fetch live data" and skipped the write — explaining
multi-hour staleness gaps where one of the two endpoints had a transient
issue but the other was healthy.

Switch to Promise.allSettled and emit whatever succeeded. Log which side
failed so future incidents are visible in prod logs. Only throw when both
fail, so we still skip the write (rather than emitting empty live data
that would mark every attraction CLOSED via implicit-closed semantics).
Copilot AI review requested due to automatic review settings May 13, 2026 08:44
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Hardens the Universal Studios Japan destination’s buildLiveData() so transient failures of one CDN endpoint (wait times vs show list) don’t suppress all live-data emission, reducing prolonged staleness in downstream collectors.

Changes:

  • Replace Promise.all with Promise.allSettled for the two CDN fetches in buildLiveData().
  • Emit partial live data from whichever fetch succeeds, while logging which side failed.
  • Still throw when both endpoints fail to avoid emitting an empty live-data set.

// rather than emitting an empty live-data set (which would mark every
// attraction CLOSED via the wiki's implicit-closed semantics).
if (waitTimeResult.status === 'rejected' && showListResult.status === 'rejected') {
throw waitTimeResult.reason;
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.

2 participants