themeparks - v9.0.0
    Preparing search index...

    Interface HistorySpan

    The three dates a backfill needs, in one shape for parks and rides.

    A park's coverage document nests these under summary; an entity's carries them at the top level under different names. Without this, every caller writes the same branch before they can ask their first question.

    interface HistorySpan {
        archiveFrom: string | null;
        finalThrough: string | null;
        recordedTo: string | null;
        retrievableThrough: string | null;
    }
    Index
    archiveFrom: string | null

    First park-local day the archive holds anything for, or null.

    finalThrough: string | null

    The newest day the archive has recorded that this key may read, or null: the place to stop if you fetch each day once.

    retrievableThrough is usually today, and today's row is the day so far. Recent days can still change after that too: the archive records days 2 to 3 behind live data. recordedTo is the newest day the archive holds, so a day on or before it has been recorded. Store those, and ask for anything later once finalThrough has moved past it. The archive can occasionally re-record a past day, for example after a park's feed is repaired; fetch that range again if you need the correction.

    The earlier of recordedTo and retrievableThrough, because a key may be entitled to fewer days than the archive holds. Null when either is unknown.

    recordedTo: string | null

    Newest day in the archive, or null. Runs a few days behind live data.

    retrievableThrough: string | null

    Newest day YOUR key may retrieve, or null.

    This, not recordedTo, is the end date to bound a backfill by: it is what the plan allows rather than what exists, and asking past it is how a long run ends in 403s.