feat: Use Blob protocol #132
Merged
Conversation
This file contains 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
Website preview 🔗✨ |
alanshaw
approved these changes
Oct 11, 2024
| // the Store protocol. Note that the Blob attempt can throw *or* return an | ||
| // error in the result. | ||
| return client.capability.blob.get(shard.multihash).then((result) => { | ||
| if (result.error) throw result.error |
There was a problem hiding this comment.
Might be good to distinguish between a service error and a 404 here and only retry on 404.
| { cause: [blobErr, storeErr] } | ||
| ) | ||
| }) | ||
| }) |
There was a problem hiding this comment.
Minor, but I find using then/catch in an async function jarring. Why not just use try/catch?
There was a problem hiding this comment.
Yeah, I was trying to find a more elegant way to write this, but for some reason it was more complicated the other way. Not sure why—in the light of morning, it's totally fine. 😛 Rewritten.
| fetcher: async () => { | ||
| if (!client || !space) return | ||
| if (!client || !space || !(isCARLink(shard))) return |
There was a problem hiding this comment.
Does it matter if it's not a CAR shard?
There was a problem hiding this comment.
Yeah, client.capability.store.get(shard) takes a CARLink. Why this wasn't failing before I can't explain; it's red in my editor. 😕
| export default function ItemPage ({ params }: PageProps): JSX.Element { | ||
| const [{ client, spaces }] = useW3() | ||
| const spaceDID = decodeURIComponent(params.did) | ||
| const space = spaces.find(s => s.did() === spaceDID) | ||
| const root = parseLink(params.cid) | ||
| const shard = parseLink(params.shard) | ||
| const shard = parseLink(params.shard).toV1() |
There was a problem hiding this comment.
Possibly not in theory, but CARLink is defined as v1 specifically. It's probably an accident, as 1 is the default for the type parameter. But it's either this or type guard for v1, and we may as well accept v0 and convert it, since it's both simpler to write and accepts more input.
Peeja
pushed a commit
that referenced
this pull request
Oct 16, 2024
🤖 I have created a release *beep* *boop* --- ## [1.13.0](w3console-v1.12.0...w3console-v1.13.0) (2024-10-11) ### Features * Use Blob protocol ([#132](#132)) ([308837e](308837e)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Peeja
added a commit
that referenced
this pull request
Oct 17, 2024
This is breaking in some cases because w3up doesn't expect effects to be links, but they sometimes are (and it should be legal for them to be). Revert, will fix and redeploy. Reverts #132
Peeja
added a commit
that referenced
this pull request
Oct 21, 2024
Reverts #134 (which reverted #132) Last night, this was still failing locally. This morning it's working again. I've done nothing but investigate. I now think the Blob protocol was a red herring. I think something else caused us to send a receipt that the client chokes on, and that that'll happen regardless of this change. If it comes back, we should investigate further, but I don't think this is what did it.
fforbeck
pushed a commit
to storacha/upload-service
that referenced
this pull request
Feb 5, 2025
🤖 I have created a release *beep* *boop* --- ## [1.13.0](storacha/console@w3console-v1.12.0...w3console-v1.13.0) (2024-10-11) ### Features * Use Blob protocol ([#132](storacha/console#132)) ([308837e](storacha/console@308837e)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
fforbeck
pushed a commit
to storacha/upload-service
that referenced
this pull request
Feb 5, 2025
This is breaking in some cases because w3up doesn't expect effects to be links, but they sometimes are (and it should be legal for them to be). Revert, will fix and redeploy. Reverts storacha/console#132
fforbeck
pushed a commit
to storacha/upload-service
that referenced
this pull request
Feb 5, 2025
Reverts storacha/console#134 (which reverted storacha/console#132) Last night, this was still failing locally. This morning it's working again. I've done nothing but investigate. I now think the Blob protocol was a red herring. I think something else caused us to send a receipt that the client chokes on, and that that'll happen regardless of this change. If it comes back, we should investigate further, but I don't think this is what did it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Reopens #118 against
main, and should address @alanshaw's feedback (making the Shard page work again).