fix: replace stewardship sync check with local chunk probe (#299)#747
Merged
Conversation
* fix: replace stewardship sync check with local chunk probe Direct (non-deferred) uploads already push chunks to the network with a confirmed receipt before the upload call resolves, so the post-upload sync screen's isReferenceRetrievable check was re-verifying something already guaranteed - and, being a full per-chunk network re-traversal, its cost scaled with chunk count and routinely took minutes or timed out for anything beyond a handful of chunks, even on a healthy network. Replace it with a single local probeData (HEAD /bytes) call plus one retry, each bounded by an explicit AbortSignal timeout so a hung request can't stall the UI indefinitely. Add an indeterminate mode to LinearProgressWithLabel so the bar animates instead of sitting frozen at 0% while the check runs. Fixes SPDV-1413 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: reset sync state when reference changes syncProgress/probeFailed were never reset on a reference/beeApi change, so navigating between two uploaded files' Share pages without a full unmount could show a stale 100% or failure message carried over from the previous file. Addresses Copilot review feedback on #299. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: correctly apply linearProgressProps to LinearProgress linearProgressProps was declared but never actually forwarded - it was spread onto <LinearProgress> as a prop named "linearProgressProps" via {...props}, which also blocked value/variant from being overridden. Destructure it explicitly and spread it onto the underlying component instead. Addresses Copilot review feedback on #299. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: avoid misleading 0% label on probe failure When probeData failed, syncProgress stayed at 0 and indeterminate was false, so the bar showed "0%" right next to text saying the upload succeeded. Add a label override to LinearProgressWithLabel and use it to show "Unknown" instead of a percentage in that state. Addresses Copilot review feedback on #299. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: don't schedule retry after unmount/reference change The first-attempt failure branch scheduled a retry unconditionally, without checking isMounted, so a rejection arriving after unmount (or a reference/beeApi change) could still trigger an unnecessary extra probeData request. Guard the whole catch block on isMounted, and abort the in-flight request on cleanup so it doesn't keep running pointlessly either. Addresses Copilot review feedback on #299. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
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
1 participant
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.
Direct (non-deferred) uploads already push chunks to the network with a confirmed receipt before the upload call resolves, so the post-upload sync screen's isReferenceRetrievable check was re-verifying something already guaranteed - and, being a full per-chunk network re-traversal, its cost scaled with chunk count and routinely took minutes or timed out for anything beyond a handful of chunks, even on a healthy network.
Replace it with a single local probeData (HEAD /bytes) call plus one retry, each bounded by an explicit AbortSignal timeout so a hung request can't stall the UI indefinitely. Add an indeterminate mode to LinearProgressWithLabel so the bar animates instead of sitting frozen at 0% while the check runs.
Fixes SPDV-1413