Opened at 2021-08-16T20:01:07Z
Closed at 2021-09-01T14:45:35Z
#3767 closed task (fixed)
Potential issues with `POST /v1/lease/<share-index>`
| Reported by: | itamarst | Owned by: | exarkun |
|---|---|---|---|
| Priority: | normal | Milestone: | HTTP Storage Protocol |
| Component: | unknown | Version: | n/a |
| Keywords: | Cc: | ||
| Launchpad Bug: |
Description (last modified by exarkun)
"If there are no shares for the given storage_index then NOT FOUND is returned."
- Does this mean... the data wasn't uploaded? The data was uploaded but expired? The bucket was created with 0 shares (this seems like it should be disallowed)?
- This is given same status code, 404, as the renew secret being wrong, but it seems rather different? Wrong secret is not the same thing as any variant of "that secret is good, but there is no data". "410 Gone" for no data, maybe?
Can you also expand the bit about mutables? Why is mutable data even happening here? Can there be a different response code for the mutable case (a redirect?).
Change History (3)
comment:1 Changed at 2021-08-18T13:52:03Z by exarkun
- Description modified (diff)
comment:2 Changed at 2021-08-19T19:29:24Z by exarkun
comment:3 Changed at 2021-09-01T14:45:35Z by itamarst
- Resolution set to fixed
- Status changed from new to closed
Note: See
TracTickets for help on using
tickets.
I don't really understand why lease renewal on mutables has this nodeid thing. Or... I don't understand why mutables and immutables differ in this. If you try to renew a lease on an immutable with a renewal secret that matches no lease on the bucket then it raises an IndexError? at you telling you your secret is unknown. If you try to renew a lease on a *mutable* with a renewal secret that matches no lease on the bucket then it raises an IndexError? at you telling you your secret is unknown *and* giving you the nodeid on which all leases it does know about were created. I suppose I see the point of the latter behavior (though I always misunderstood it until just now). If storage1 is decommissioned in some orderly fashion and all of its storage is taken over by storage2 then when the client shows up to renew leases for shares originally uploaded to storage1 it will compute a different renewal secret because it will use storage2's id as part of the hash input. So the renew is going to fail because the different renewal secret no longer matches the lease the client expects to be renewing. Fine. I suppose that putting the information into the text content of an IndexError? means that nothing ever _actually_ uses it and ... something else happens, I dunno what. But whatever. So why does that logic apply only to mutables, not immutables? Is it just the unsurprising consequence of having two nearly identical codepaths implementing what should really be the same thing? They eventually unintentionally diverged? "eventually" being 68d3d620026330bc14fc27218f1c81023188c657 in 2007...