Skip to content

Harden imported artifact remote page fallback#1231

Open
lupuszr wants to merge 1 commit into
mainfrom
codex/imported-artifact-blob-discovery
Open

Harden imported artifact remote page fallback#1231
lupuszr wants to merge 1 commit into
mainfrom
codex/imported-artifact-blob-discovery

Conversation

@lupuszr

@lupuszr lupuszr commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

Summary

Changes

Test Plan

  • Tests pass locally (pnpm test)
  • Build succeeds (pnpm build)
  • Manually tested with dkg start (if applicable)

Related Issues

return { availability: 'unverified_page', remote, sourcePeerId };
const result: AssertionArtifactRemoteResult = { availability: 'unverified_page', remote, sourcePeerId };
if (opts.cache && !opts.explicitSourcePeerId) {
fallback ??= result;

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🔴 Bug: fallback ??= result leaves an earlier unavailable/denied/hash-mismatch fallback in place even after a later peer returns a usable unverified page. With default cache promotion and no explicit sourcePeerId, a candidate list like [unavailable-peer, large-artifact-peer] now scans past the large artifact's unverified page, but returns the first unavailable response when no fully verified peer is found. This regresses remote reads for large or otherwise non-cache-promotable artifacts. Replace lower-priority unavailable fallbacks with the first unverified_page fallback while still continuing to look for a verified peer.

This keeps the first fallback even when it is only unavailable, so a later valid unverified_page can be discarded. With discovered peers, cache enabled, and no explicit source, a sequence like peer-down then peer-large-valid-but-unverified now returns the earlier unavailable result instead of the usable unverified page. Prefer the unverified result over an unavailable fallback, or track fallback priorities separately.

}));
});

it('rejects an oversized unverified remote page', async () => {

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: This only exercises the cache: false readRequestedPage path. The PR also added decoded-length guards in the cache-promotion path for the first page and subsequent pages, which is the path that can assemble verifiedBytes and promote bytes into the file store. A regression in those guards would not fail this suite. Add cache: true cases for an oversized first page and an oversized later page, asserting hashMismatch, bytesB64 cleared, and no verifiedBytes.

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