ARTIFACT SERVICE · VERSIONS AND READERS

Artifact service contract: assemble, commit and read

Write a three-section report into a versioned artifact store while another reader loads it, and see which version that reader actually gets.

Computed experiment · sixty inspection seconds

Your experiment

The writer saves report.pdf after each of three sections, so every save creates a new version, and a reader loads the latest version 15 seconds in. Find out what the reader receives, then assemble before saving, read the announced version, crash the writer and read from another session.

Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.

Event trace

    Computed data

    Final metrics

    Modeled on ADK artifact-service semantics (every save of a name creates the next integer version, the first being 0; a load without a version returns the latest; a user: prefix shares the name across a user’s sessions). No artifact service, storage bucket or ADK runtime is called. Sections are written at 10, 20 and 30 s; the announcement is a fixture event at 31 s; version 0 is a complete report from an earlier turn.

    Every save is a new version

    An artifact service stores named binary documents outside session state. Each save of a name creates the next integer version, starting at 0, and a load without a version returns the latest one. The fixture already holds report.pdf version 0, the complete Q2 report from an earlier turn. Now a writer produces the Q3 report in three sections, written at modeled times t=10, 20 and 30 s, while a reader loads the report. Every time in this guide is that modeled clock, the t= value in the trace; the replay spreads the events over sixty inspection seconds. How the writer saves decides which versions exist; How the reader loads and Reader starts at decide which one the reader gets.

    The opening run: a partial report, served as latest

    The writer saves after every section, so the store gains version 1 at 10 seconds (1 of 3 sections), version 2 at 20 and version 3 at 30, the complete report. The reader loads the latest version at 15 seconds and receives version 1: a valid, readable file with one third of the content. Nothing failed; latest simply meant the most recent save. Read at 45 seconds instead and latest is version 3, complete. A reader that cares about completeness cannot rely on timing.

    Failure boundary: what is safe to load

    Choose Assemble, then save once: there is a single save, version 1 at 30 seconds, but a reader at 15 seconds now gets version 0, last quarter’s report, which is just as wrong. Choose The version the writer announces: the reader waits for the writer’s completion event at 31 seconds and loads exactly that version (3 when saving per section, 1 when assembling), whatever its start time. Set Writer crash to after section 1 or 2: saving per section leaves a partial version as latest forever, assembling leaves only the old version 0, and the announced reader reports the report as unavailable instead of returning either.

    Namespaces: session and user

    report.pdf is session-scoped: set Reader’s session to another session S2 of the same user and the reader finds no such artifact at all. The name user:report.pdf is user-scoped, so the S2 reader sees the same versions as S1, including the partial ones. Scope decides who can see a name, not which version is complete; switching to user scope with the latest reader at 15 seconds still returns the partial version 1. Reader starts at matters only to the latest reader, and the artifact name matters only when the reader is in another session.

    Reading the run and its limits

    Play replays the saves, any crash, the announcement, the read and the outcome over sixty inspection seconds in time order; Next event, Restart, Speed and Inspection time control the replay, and any input change recomputes it. The table lists every version with its save time, content and whether it belongs to this run. The store is a fixture modeled on ADK’s artifact contract; there is no bucket, upload, garbage collection or concurrent writer here, and the completion announcement stands in for whatever event or state key a real application uses to publish a version number.

    Views are my own and do not represent any employer, past or present.

    Search