Last Comment Bug 871871 - Submitting a review fails with a 409 Conflict
: Submitting a review fails with a 409 Conflict
Product: Marketplace
Classification: Server Software
Component: Consumer Pages (show other bugs)
: 1.0
: All Gonk (Firefox OS)
P1 normal (vote)
: 2013-05-16
Assigned To: Davor Spasovski [:spasovski]
Depends on:
Blocks: 859511
  Show dependency treegraph
Reported: 2013-05-13 19:12 PDT by krupa raj[:krupa]
Modified: 2013-05-22 06:48 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image krupa raj[:krupa] 2013-05-13 19:12:50 PDT
steps to reproduce:
1. Navigate to the details page for Twitter
2. Navigate to the review details page
3. Click on "Write a review"
4. Select a rating and then add a comment
5. Click Submit

observed behavior:
Review submission fails with a 409 Conflict

http request [
POST /api/v1/apps/rating/?_user={blah blah}&dev=firefoxos&format=json&lang=pl&pro=fbff7fdc.32.1&region=us HTTP/1.1
User-Agent: Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0
Accept: */*
active [1] { handler=48766cf0 condition=0 pollflags=5 }
active [0] { handler=46fa7f20 condition=0 pollflags=5 }
idle [0] { handler=47ab78e0 condition=0 pollflags=6 }
active=3 idle=1
active=3 idle=0
calling PR_Poll [active=3 idle=0]
timeout = 65535000 milliseconds
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 30
Cookie: __utma=117863061.1412236192.1368473654.1368483634.1368496327.3; __utmz=117863061.1368473654.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=117863061.18.10.1368496327; __utmc=117863061; lang="pl\054"; region=us; carrier=telefonica
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
nsHttpTransaction::HandleContentStart [this=440361d0]
Duration:        0.873 440361d0       ( -> POST /api/v1/apps/rating/?
 http response [
Server: gunicorn/0.17.4
Vary: API-Filter, X-Requested-With, Accept-Language, Cookie, X-Mobile, User-Agent, Accept-Encoding
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Access-Control-Expose-Headers: API-Filter, API-Status, API-Version
Strict-Transport-Security: max-age=2592000
Date: Tue, 14 May 2013 02:05:38 GMT
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
X-Content-Security-Policy-Report-Only: policy-uri /services/csp/policy?build=9e9e
Via: Moz-pp-zlb09
Connection: keep-alive
API-Filter: carrier=telefonica&device=gaia&lang=pl&region=us
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: X-HTTP-Method-Override, Content-Type
API-Version: 1
Comment 1 User image Wil Clouser [:clouserw] 2013-05-15 10:59:24 PDT
Andy: we're not sure if this is in the API or not.  Can you investigate and work with #amo for questions?

If it's blocking all reviews we can't push with it
Comment 2 User image Christopher Van Wiemeersch [:cvan] 2013-05-15 10:59:34 PDT
API docs say "409 – the user has previously rated the app, so Update should be used instead."
Comment 3 User image Matt Basta [:basta] 2013-05-15 11:00:47 PDT
If we get a has_rated, we always show an Edit Review button. If we get a can_rate or the user isn't signed in, we show a Write a Review button.

Either way, there shouldn't be a case where we are hitting the wrong URL. We have pretty good tests that test that we're doing the right thing, so I'm pretty sure this is the API being out of sync.

Why doesn't posting a new review overwrite an existing review for that app? That seems like appropriate behavior in this case.
Comment 4 User image Andy McKay [:andym] 2013-05-16 09:29:28 PDT
I think its perfectly reasonable for the API to enforce correct HTTP headers being sent. I haven't been able to reproduce this yet, it works fine on stage and -dev for me.
Comment 5 User image krupa raj[:krupa] 2013-05-16 09:54:16 PDT
1. Log in to marketplace-dev
2. Go to the details page for an app like Accuweather
3. Add a review
4. Log out
5. Reload the page (I used a different browser because of
6. As an anonymous user, click on 'Write a review' button
7. Log in with the same credentials used in #1
8. Add a review.

expected behavior:
Once the user logs in, we detect that they have added a review already and load the Edit review screen.

observed behavior:
We load the Write review form and submission fails.
Comment 6 User image Andy McKay [:andym] 2013-05-16 10:10:15 PDT
In #remora both chuck and I think this is an issue in fireplace.
Comment 7 User image Chuck Harmston [:chuck] 2013-05-16 10:37:27 PDT
Yeah, it appears that after step #7 in Krupa's STR, Fireplace doesn't check for `has_rated` on the newly-authenticated user and adjust the displayed form appropriately.
Comment 8 User image Davor Spasovski [:spasovski] 2013-05-16 14:48:38 PDT
This should force a login to get to any add/edit review page.
Comment 9 User image Victor Carciu 2013-05-22 06:48:36 PDT
Verified as fixed using STRs from comment #5.
Please see screencast with "Edit review" button in Chrome :

Note You need to log in before you can comment on or make changes to this bug.