I just started seeing a problem when I save a disc that is not yet available (i.e., save it to the "Saved Discs" queue). Adds of currently available discs are working fine, but saves of not yet available discs return a response code of "304 - not modified". If I then fetch the contents of the saved queue, the disc is in fact there. So it looks like the operation is succeeding but reporting a failure.
Rich,
can you send me the request you are sending? Are you sending an "etag" parameter in the request (or etag header). I recently made a change to etag caching, and it looks like you are hitting this..
I'm doing a post to /users/<user id>/queues/disc with a body of: title_ref=http%3A%2F%2Fapi.netflix.com%2Fcatalog%2Ftitles%2Fmovies%2F70099111&etag=58561912277. I'm not setting an etag header. This had been working until recently. This request works correctly when the disc is available and ends up in the available disc queue. Should I be doing something different? Thanks.
Hey rich,
Looks like we have a bug generating the etag. We are not considering the saved movies.. Should have a fix out for this within a week. To get around this, you can not pass in the "etag" parameter in the post.
=mikey-=
Is there really any need to pass the etag at all? I assume that if the title was already in the queue, I'd get a failure whether or not I provide the etag. Any other scenarios where the etag buys me anything? Thanks.
The etag gets you caching. if you pass an etag the the resource etag matches the passed in etag, you will get a 304 not modified, so you can used the cached version. If you are not doing any caching, there is no need to pass the etag.
Hi mickey,
I'm a little confused by your response. I'm posting an add to the disc queue, and the etag I pass in is the one I got last time I fetched something from the disc queue. Normally I would expect the etags to match and the add to succeed. If the etags don't match, then I would assume that the queue had been modified by something external to my app. I could see the add failing in this case, although my application never specifies queue position and takes the default of adding to the end. So I'm happy with the add always succeeding unless there's something invalid in the request.
I currently cache queue fetch results, and if I see the etag change, I drop cached entries and refetch as needed. If I can trust the etag mechanism to work for queue adds, I could be smarter about dropping cache entries. If I know that the etag changed in response to the add I just did, then I don't need to clear the cache, just add the new title at the end.
Rich,
I think I did confuse you, as I did myself here. First, I should say that we do have a couple of bugs that you are hitting. One involves etags. I am working on some etag related stuff for our next version, and some of this functionality accidentally creeped in with unintended consequences. The other bug involves how the queue etag is calculated. The etag should consider the saved and the available queues, and it is not.
To clarify how the etag should work for adding to the queue, you are correct, we only check if the etag matches if you add to a position or move an item and pass the etag; the add without a position should always work regardless of the etag passed in. But since I broke some of this etag stuff recently, a matching etag will return a 304 instead of a 201.
Hopefully, I haven't confused you further, but we will get this fixed asap (hopefully today or tomorrow it can go live.)
I just started seeing a problem when I save a disc that is not yet available (i.e., save it to the "Saved Discs" queue). Adds of currently available discs are working fine, but saves of not yet available discs return a response code of "304 - not modified". If I then fetch the contents of the saved queue, the disc is in fact there. So it looks like the operation is succeeding but reporting a failure.
Message edited by Rich Knox 3 years ago
Tags
mikey – 3 years ago
Rich,
can you send me the request you are sending? Are you sending an "etag" parameter in the request (or etag header). I recently made a change to etag caching, and it looks like you are hitting this..
Rich Knox – 3 years ago
I'm doing a post to /users/<user id>/queues/disc with a body of: title_ref=http%3A%2F%2Fapi.netflix.com%2Fcatalog%2Ftitles%2Fmovies%2F70099111&etag=58561912277. I'm not setting an etag header. This had been working until recently. This request works correctly when the disc is available and ends up in the available disc queue. Should I be doing something different? Thanks.
mikey – 3 years ago
Hey rich,
Looks like we have a bug generating the etag. We are not considering the saved movies.. Should have a fix out for this within a week. To get around this, you can not pass in the "etag" parameter in the post.
=mikey-=
Rich Knox – 3 years ago
Is there really any need to pass the etag at all? I assume that if the title was already in the queue, I'd get a failure whether or not I provide the etag. Any other scenarios where the etag buys me anything? Thanks.
mikey – 3 years ago
The etag gets you caching. if you pass an etag the the resource etag matches the passed in etag, you will get a 304 not modified, so you can used the cached version. If you are not doing any caching, there is no need to pass the etag.
Rich Knox – 3 years ago
Hi mickey,
I'm a little confused by your response. I'm posting an add to the disc queue, and the etag I pass in is the one I got last time I fetched something from the disc queue. Normally I would expect the etags to match and the add to succeed. If the etags don't match, then I would assume that the queue had been modified by something external to my app. I could see the add failing in this case, although my application never specifies queue position and takes the default of adding to the end. So I'm happy with the add always succeeding unless there's something invalid in the request.
I currently cache queue fetch results, and if I see the etag change, I drop cached entries and refetch as needed. If I can trust the etag mechanism to work for queue adds, I could be smarter about dropping cache entries. If I know that the etag changed in response to the add I just did, then I don't need to clear the cache, just add the new title at the end.
mikey – 3 years ago
Rich,
I think I did confuse you, as I did myself here. First, I should say that we do have a couple of bugs that you are hitting. One involves etags. I am working on some etag related stuff for our next version, and some of this functionality accidentally creeped in with unintended consequences. The other bug involves how the queue etag is calculated. The etag should consider the saved and the available queues, and it is not.
To clarify how the etag should work for adding to the queue, you are correct, we only check if the etag matches if you add to a position or move an item and pass the etag; the add without a position should always work regardless of the etag passed in. But since I broke some of this etag stuff recently, a matching etag will return a 304 instead of a 201.
Hopefully, I haven't confused you further, but we will get this fixed asap (hopefully today or tomorrow it can go live.)
thanks!
=-mikey-=