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
This is going to be pretty tricky. The current way if_not_exists is implemented is:
Make the request with if-none-match
If the request succeeded, return the response.
If you got a 412, then it existed. The real value was returned, but not its permissions. Fetch its permissions.
For this to work in a batch, the request would have to enqueue some kind of post-request processing, and that processing might need to issue another batch of requests. Tying all of that together seems complicated and error-prone.
I'm trying to think if there's a larger solution here and I'm not really seeing one. Even if we had something like Futures to tie the results of a batch to the requests, we'd still need some kind of after-response-with-potentially-new-batch mechanism, which is ugly. There's also the fact that what we have right now isn't really re-entrant. It's possible that the first request gets a 412, but the conflicting record gets deleted before the second request, which gets a 404. Right now we don't handle this at all, but we could imagine the second request re-triggering the first request, which could retrigger the second request, on and on forever.
I feel like the right solution here is to change the server to return the permissions as well as the data on a 412. If we did that, then we would never need a follow-up request and we could just add some kind of post-processing that transformed 412 responses. But I'm not sure this is extensible. Is it possible for Kinto plugins to add other fields to record responses, but not to 412 responses?
The if_not_exists behavior doesn't ignore the 412 if they happen in a batch.
The text was updated successfully, but these errors were encountered: