STR: - Set your region to France - Search for "MessageMe" Expected: - You don't find the app "MessageMe" because it's excluded from this region Actual: - You find "MessageMe" and can go to its detail page, however reviews won't load because of the region restriction. Did we forget to reindex when adding new regions ?

Here's the ashes ID I got from submitting the logs: 664a6

I just checked ES and the db and the region exclusions match and include region=30 (France).

It looks like the issue is with geoip on the client-side. If I manually set my region to France using the debug page, everything works fine. If I don't however, and rely on geoip, consumer_info returns "fr", but somehow this is never passed to the API requests. You can see this in :magopian's ashes, all his API calls are made without passing the region parameter. Because of CDN caching the search API endpoint should always be passed the region, so something is wrong in the client side here. It could be because of the recent changes in consumer_info. New STR: - Start Marketplace without a SIM card from a region that we support (make sure you are *not* using a region override in the debug page, the region must come from geoip detection) - Verify that the region is displayed correctly in the bottom right corner - With network tab opened in the developer tools, make a search - Check that the region=<xx> is sent with the API call for the search (/api/v1/fireplace/search/...) Expected: - The region you are using is sent (for instance, region=fr in France) Actual: - The region is not sent :(

Looks like this is broken since https://github.com/mozilla/fireplace/commit/76a2dc1041a3f5f652fe5c8035476ccb523c1f41 - we no longer call set_region_geoip()... I don't think we had any tests :(

(In reply to Mathieu Pillard [:mat] from comment #4) > Looks like this is broken since > https://github.com/mozilla/fireplace/commit/ > 76a2dc1041a3f5f652fe5c8035476ccb523c1f41 - we no longer call > set_region_geoip()... I don't think we had any tests :( Man, that's unfortunate

Fixed in https://github.com/mozilla/fireplace/commit/2d1e1802d15ecb7c4fffce061618d73baa65b7cc Use STR from comment 3 to verify this bug.

We are not able to verify this bug from our region(Romania). Krupa can you or someone else test this from US?

USECASE 1: No SIM associated with the phone STR 1. Make sure your phone has no SIM 2. Flash your phone and fresh install packaged stage app 3. Launch the stage app without a SIM in the phone 4. Check that the region is correctly set to US 5. Search for an app and check adb logcat or app manager observed behavior: works fine. region is set to US as expected. 08-04 18:45:29.131 E/GeckoConsole( 1454): Content JS LOG at app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [nav] Received navigate event: /search?q=face 08-04 18:45:29.131 E/GeckoConsole( 1454): Content JS LOG at app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [nav] Updating scrollTop with replaceState 08-04 18:45:29.131 E/GeckoConsole( 1454): Content JS LOG at app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [nav] Navigation started: /search?q=face 08-04 18:45:29.131 E/GeckoConsole( 1454): Content JS LOG at app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [views] Routing /search 08-04 18:45:29.131 E/GeckoConsole( 1454): Content JS LOG at app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [req] Opening pool 08-04 18:45:29.141 E/GeckoConsole( 1454): Content JS LOG at app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [req] GETing https://marketplace-stage.cdn.mozilla.net/api/v1/fireplace/search/?cache=1&dev=firefoxos&device=firefoxos&lang=en-US&limit=10&q=face&region=us&vary=0 08-04 18:45:29.141 E/GeckoConsole( 1454): Content JS LOG at app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [tracking] Tracking page view /search?q=face 08-04 18:45:29.141 E/GeckoConsole( 1454): Content JS LOG at app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [nav] Navigation loop truncated: 08-04 18:45:29.141 E/GeckoConsole( 1454): Content JS LOG at app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [nav] Pushed state onto stack: /search?q=face 08-04 18:45:29.361 E/GeckoConsole( 1454): Content JS LOG at app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [nav] Setting scroll to 0 08-04 18:45:30.271 E/GeckoConsole( 1454): Content JS LOG at app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [req] GOT https://marketplace-stage.cdn.mozilla.net/api/v1/fireplace/search/?cache=1&dev=firefoxos&device=firefoxos&lang=en-US&limit=10&q=face&region=us&vary=0 USECASE 2: If the phone was associated with a SIM previously STR: 1. Flash your phone and fresh install packaged stage app 2. Remove the SIM if there is any in the phone (I had a polish DT SIM) 3. Launch the stage app without a SIM in the phone 4. Check that the region is correctly set to US 5. Search for an app and check adb logcat or app manager expected behavior: The region you are using is sent in the API request actual behavior: region is missing app://packaged.marketplace.allizom.org/media/js/include.js:6 in l/s/<: [req] GOT https://marketplace-stage.cdn.mozilla.net/api/v1/fireplace/search/?cache=1&dev=firefoxos&device=firefoxos&lang=en-US&limit=10&q=facebook&vary=0 ashes:f3cfd Note that in ashes, [req] GETing https://marketplace.allizom.org/api/v1/fireplace/consumer-info/?carrier=deutsche_telekom&dev=firefoxos&device=firefoxos&lang=en-US&limit=10&region=pl <--- is incorrect since the SIM was removed. Reopening the bug so that Mat can review the code again.

I've look at the code and ashes carefully and I don't think it's a new issue. From those ashes, it appears that we are calling consumer_info too early, before mobilenetwork detection. So what happens is this: - Marketplace is launched. We already have the region & carrier stored in the settings for the current user. - We call consumer_info. We pass it the region and carrier from the settings - consumer_info doesn't overwrite the region (since we already have one) - mobilenetwork is called, detects that we no longer have a SIM card, and sets region and carrier to null - All subsequent API calls are made without a region and carrier. I'm fairly sure this isn't a new regression, since we haven't made changes to mobilenetwork logic recently. Or maybe the problem was just hidden by something else before. Not storing the region/carrier info to settings and/or calling mobilenetwork before consumer_info would solve this problem. But this should happen in another bug IMHO, so we can properly discuss this. This would even be a good time to look at refactoring mobilenetwork code (https://github.com/mozilla/fireplace/pull/373) again.

Krupa: the original issue (usecase 1 in your tests) is fixed, I'm closing this bug again and we'll deal with the other use cases in https://bugzilla.mozilla.org/show_bug.cgi?id=1048877