fix(peerclient): resolve base path per-call from live FrameTable#2585
Draft
fix(peerclient): resolve base path per-call from live FrameTable#2585
Conversation
After a peer→storage transition, peerSeekable kept opening base against the original (uncompressed) path captured at construction. With the recent compression work, post-transition reads now target a compressed object, so the cached base resolved to a non-existent path. P2P routing produced the stale binding (it captured a path while the build was still uncompressed); it also contains the fix. peerSeekable now holds (buildID, basic name, base provider, objType) and composes the actual storage path at base-open time using the CompressionType from the live FrameTable. The base seekable is reopened on ct change. No changes outside peerclient — no cache key, no chunker, no public storage interface. Also hoist the transition emit to the top of OpenRangeReader: returning PeerTransitionedError no longer wastes a base open before the caller swaps the header and retries.
❌ 4 Tests Failed:
View the full list of 8 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The removal of nil checks for the uploaded atomic pointer in OpenRangeReader and tryPeer introduces potential nil pointer dereferences. A transition to storage occurring during a peer read attempt may be missed, causing the base storage to be opened with a stale compression type; re-checking the transition state after the peer attempt is necessary to ensure the caller refreshes the compression state correctly.
| // Emit at most once per peerSeekable so V3 builds (no V4 to upgrade to) | ||
| // don't loop against this error. No peer call, no base open — caller | ||
| // retries with the live compression type already in the new FrameTable. | ||
| if s.uploaded.Load() && s.transitionEmitted.CompareAndSwap(false, true) { |
There was a problem hiding this comment.
The defensive check for a nil uploaded atomic pointer was removed in this refactoring. While the provider is typically initialized with this atomic, the original implementation included this check to prevent panics in edge cases where the routing might not provide it. Restoring the check ensures the code remains robust against variations in the initialization path.
Suggested change
| if s.uploaded.Load() && s.transitionEmitted.CompareAndSwap(false, true) { | |
| if s.uploaded != nil && s.uploaded.Load() && s.transitionEmitted.CompareAndSwap(false, true) { |
Comment on lines
+134
to
+136
| if res.hit { | ||
| return res.value, err | ||
| } |
There was a problem hiding this comment.
A transition to storage that occurs during the tryPeer call will be missed, potentially leading to path resolution errors. If the peer signals a transition during the read attempt, tryPeer returns a non-hit result, and the code proceeds to open the base storage using the stale compression type from the current frameTable. Re-checking the transition state after the peer attempt ensures the caller is correctly prompted to refresh its header and compression state when a transition is detected mid-call.
if res.hit {
return res.value, err
}
if s.uploaded != nil && s.uploaded.Load() && s.transitionEmitted.CompareAndSwap(false, true) {
return nil, &storage.PeerTransitionedError{}
}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After a peer→storage transition, peerSeekable kept opening base against the original (uncompressed) path captured at construction. With the recent compression work, post-transition reads now target a compressed object, so the cached base resolved to a non-existent path.
P2P routing produced the stale binding (it captured a path while the build was still uncompressed); it also contains the fix. peerSeekable now holds (buildID, basic name, base provider, objType) and composes the actual storage path at base-open time using the CompressionType from the live FrameTable. The base seekable is reopened on ct change. No changes outside peerclient.