You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Update spec to make address required to prevent cascading failures when field is omitted.
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.
The text was updated successfully, but these errors were encountered:
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
Per storacha/w3up#1342 (comment)
Spec declares
address
field in theblob/allocate
receipt as optional, but then in thehttp/put
awaits on theaddress.url
andaddress.headers
which is means that task will fail whenaddress
is omitted, which consequently will failblob/accept
which depends onhttp/put
.We should either
address
required to prevent cascading failures when field is omitted.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.
The text was updated successfully, but these errors were encountered: