Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blob/allocate should not have optional address #120

Open
Gozala opened this issue Apr 12, 2024 · 1 comment
Open

blob/allocate should not have optional address #120

Gozala opened this issue Apr 12, 2024 · 1 comment
Assignees

Comments

@Gozala
Copy link
Collaborator

Gozala commented Apr 12, 2024

Per storacha/w3up#1342 (comment)

Spec declares address field in the blob/allocate receipt as optional, but then in the http/put awaits on the address.url and address.headers which is means that task will fail when address is omitted, which consequently will fail blob/accept which depends on http/put.

We should either

  1. Update spec to make address required to prevent cascading failures when field is omitted.
  2. Describe execution flow for a case where address is not present.

In the implementation PR @vasco-santos made point that in the future allocation would imply finding candidate storage nodes and allocating space with them, which is probably not something we would want to do if content is already available (on some storage node), so perhaps extending execution flow to cover such scenario might be a good idea.

On the other hand we could just make field required and come back to the updated flow when are doing candidate storage node selections.

@Gozala Gozala self-assigned this Apr 12, 2024
@vasco-santos
Copy link
Contributor

Yeah, so I see value on

which is probably not something we would want to do if content is already available (on some storage node), so perhaps extending execution flow to cover such scenario might be a good idea.

but I do not mind making address required for now. Also, this is internal and not affecting client as far as I can tell, sxo we won't need to coordinate client updates

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Ice Box
Development

No branches or pull requests

2 participants