fix: serve versioned live mount image previews #41
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "t3/fix-binary-preview-version"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Live-mount image previews requested a version through the stored-history path, so readable images returned 404 when the provider correctly reported that revision history is unsupported. Restore versioned live previews under ADRs 0015 and 0034 without changing stored historical delivery.
What's in
Tests
No UI rendering or URL changes; delivery was verified through real gated HTTP integration tests, so browser automation and screenshots were unnecessary. No schema, ADR, seed or submodule changes. Independent full-suite repetitions were skipped because the final focused checks found no additional concern.
Summary
Summary
Coverage
Shikigami.BlazorAdapter - 95.6%
Shikigami.Capabilities.Contracts - 97.8%
Shikigami.Capabilities.TestFixture - 92.8%
Shikigami.Domain - 98.1%
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_0
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_2
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__MediaTypeShape_3
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__NamePattern_1
Shikigami.Infrastructure - 97.2%
on
ration
shot
234D40E1D5003482F41439E482AB211B6EAD2E13F0A9D40B0__Pattern_0
Shikigami.Kernel - 90.9%
Shikigami.Server - 100%
Shikigami.UseCases - 95.8%
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__AssignmentHead_12
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__BraceExpansion_11
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__HexColour_6
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__IdPattern_0
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Interval_3
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__IntervalBody_10
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__NameRule_5
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__NewerXY_8
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Number_7
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__OldCount_9
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__TimeOfDay_2
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__ToolPattern_1
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Window_4
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! A live-mount preview that 404'd because history was asked for bytes it never promised to remember~ How delightful, a bug born from taking a capability-agnostic path through a capability-specific world. I read every line of the diff and its surroundings, chased
FileSystem.RevisionsAsyncdown both its branches, and then — because trust is for people who don't review — I mutation-probed your tests myself. ♡Verdict: ✅ Looks good to me~
The design is exactly right, and I checked it against the siblings rather than taking it on faith:
FileSystem.RevisionsAsyncreturnsUnsupportedonly forCapabilityMountAdaptermounts (checked afterNoFamiliar/Denied, so the fallback can never bypass an access refusal) — the fallback condition is precisely aligned with the capability, not broader.RevertAsyncandPurgeHistoryAsyncstill refuse without fallback, so the "history is history" semantics survive untouched.read.Value.Entry.Version— the entry that arrives with the bytes, not a stat that may be stale — is the correct TOCTOU guard. A pane that opened at v7 gets a 404 after the image moves to v8, not silent substitution. The comment explaining this is exactly the kind of comment that earns its place.elsebranch is the original line verbatim, andA_stored_image_preview_keeps_its_historical_bytes_after_the_current_image_changespins the old bytes atv=while the current URL serves the new ones.✅ What I liked~
StatVersionknob onBinaryFixtureState— simulating a stat that still reports the old version while the read carries v8 is a lovely trap for any future regression that reintroduces a stat check. Fufu, someone thought like an attacker~ ♪MissingOnceFileStoreDispatchProxy that countsGetAsynclookups: assertingTargetLookups == 1proves no fallback read happened after history NotFound, instead of merely observing a 404 that could have come from anywhere. That's evidence, not coincidence.no-store/sandboxheaders all re-asserted for the versioned path — nothing about being "live" bought an exemption.Mutation probes (3 run, 0 survived):
A_history_NotFound_does_not_fall_back…fails ✂️A_live_preview_verifies_the_version_of_the_read_even_when_stat_still_reports_the_old_versionfails ✂️A_live_image_previews_at_its_current_version…fails ✂️Every new branch has a test that dies for it. That's all I ever ask~ ♡
Automated review by Jibril · 2026-10-22
CI: green for head SHA
20b26d203f· Mutation probes: 3 run, 0 survived / 0 skipped · Local suite: skipped (CI green; targeted probe runs only)