1003005 - Listing pages load with no content, sometimes (bug 970641 is on Tarako too)

Status: RESOLVED FIXED

(Marketplace Graveyard :: Consumer Pages, defect, P1)

Description

[krupa raj[:krupa]]

Attachment: screenshot

tarako build identifier: 20140428014001
connectivity used: wifi
noticed on: dev (latest build)

steps to reproduce:
1. Load Marketplace-dev packaged app on your tarako device
2. Click on the Games category


observed behavior:
Category section loads with no content

04-28 23:26:13.400 E/GeckoConsole( 1659): Content JS LOG at app://packaged.marketplace-dev.allizom.org/media/js/include.js:6 in l/s/<: [req] GETing https://marketplace-dev.mozflare.net/api/v1/fireplace/search/featured/?cache=1&carrier=telefonica&cat=tarako-games&dev=firefoxos&device=firefoxos&lang=en-US&limit=10&region=es&tag=tarako&vary=0
04-28 23:26:13.670 E/GeckoConsole( 1659): Content JS LOG at app://packaged.marketplace-dev.allizom.org/media/js/include.js:6 in l/s/<: [req] Request failed: GET 0

reproducible?: sometimes

Other: Well, at least this bug is an equal oppurtunity offender. See https://bugzilla.mozilla.org/show_bug.cgi?id=970641 for the same issue on Android. Looks like an API issue

I filed this to make sure we have this issue being tracked for tarako as well. 

behavior seen on regular marketplace using inari/hamachi: yes/no

Comment 1

[David Durst [:ddurst]]

Kevin -- was there progress on this stemming from bug 970641?

Comment 2

[Kevin Ngo [:ngoke]]

Yeah, I'm pretty sure. It can get the data, just the 'defer' block is having trouble injecting it into the page. Although I found a possible root issue, I had real trouble finding a good way to get around it. Here were my scratch notes. 

builder.js defer GET issue, not returning data back.
- gets past request.__cached
- that request.done doesn't look synchronous, race condition?
- are promises the solution? use injector
- UID changing
- Double defer
     - the first defer probably finishes but never seen in UI
     -  change in the placeholder ID, placeholder replaces what the first defer renders
     -  the second defer never finishes, placeholder never replaced

Comment 3

[Kevin Ngo [:ngoke]]

Still repro?

Comment 4

[krupa raj[:krupa]]

Kevin is working on this. Last irc comment went:

we're getting intermittent CORS errors causing krupa's reported "GET 0" bug
12:38 PM
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://marketplace-dev-cdn.allizom.org/api/v1/fireplace/search/featured/?cache=1&cat=tarako-games&lang=en-US&limit=10&offset=10&region=us&tag=tarako&vary=0. This can be fixed by moving the resource to the same domain or enabling CORS.
12:40 PM
maybe fire the request a second time if it's fails...

Comment 5

[David Durst [:ddurst]]

Moving to P1 because it appears to happen more frequently on Tarako (though Krupa has deemed it not a blocker)

Comment 6

[David Durst [:ddurst]]

Kevin -- given the new deferring behavior, is this still an issue (on Tarako)?

Comment 7

[krupa raj[:krupa]]

more logging for GET 0 @ https://www.dropbox.com/s/2mbo6jouu2tlur4/Screenshot%202014-05-28%2017.28.46.png

Comment 8

[Kevin Ngo [:ngoke]]

Let's try retrying requests. See if it reduces the occurrences. If you find an occurrence, please submit ashes.

https://github.com/mozilla/yogafire/commit/4352c17f83b4d9950b3403c1144a1655927dae08

Comment 9

[krupa raj[:krupa]]

Navigating to the Privacy policy link from the homepage results in a GET 0 request now.

ashes: 85d00

Comment 10

[Kevin Ngo [:ngoke]]

Took 20 minutes to reproduce, which was successfully worked around with the retry.

I added triple retries for good measure: https://github.com/mozilla/yogafire/commit/fd642b6539d6e7c9ab72a711a326d524c790f56a