1224407 - Inconsistent error UI when iOS snippet returns 429 (Too many requests)

Status: RESOLVED FIXED

(Snippets Graveyard :: General, defect)

Description

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

STR:

1. Browse to about:home on Firefox release
2. Refresh until you get the iOS snippet
3. Enter a 10-digit SMS number
4. Repeat step 3 a couple of times
5. See no response from the UI

If a user submits an SMS more than once per hour, he or she should see http://cl.ly/image/2B3i010C0u2c.

We're seeing inconsistent results where the UI won't change at all.

Stage is operating as expected: https://snippets.allizom.org/show/98/

Comment 1

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Another observation: in addition to stage preview, this is also not reproducible when configuration the Snippet Switcher to point to stage, and loading the test snippet.

Comment 2

[Paul [:pmac] McLanahan]

This must be due to basket's occasional slow response time, which I'm still trying to track down.

Comment 3

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Another observation:

When I refresh the snippet, if I get a DIFFERENT iOS snippet[0] from the last time I tried, I get the error banner as expected. If I refresh and I'm served the same snippet I just tried it on, I don't get the change of UI.

[0] Two snippets currently in rotation: (1) http://cl.ly/image/351P361T3n3e, (2) http://cl.ly/image/3t2L09412F1Y

(In reply to Paul [:pmac] McLanahan from comment #2)
> This must be due to basket's occasional slow response time, which I'm still
> trying to track down.
I'd like to blame it on this, but I really don't think this is it. The network logs are showing a response coming back very quickly.

Comment 4

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Okay! The problem was that `{{ snippet_id }}` was not included in the element id's. This became problematic when multiple snippets were loaded onto the client.

I've updated the PR here: https://github.com/mozilla/snippets/pull/60. It's a more than trivial code change, so it needs a review.

NI giorgos - could you please review and move this to production first thing your time zone? Thanks!

Comment 5

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

:jcollings, I have disabled the other US targeted snippet https://snippets.mozilla.com/admin/base/snippet/5478/. This will stop users from encountering the issue as we won't be loading multiple ID's onto the same client.

Comment 6

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Verified on a new install/profile that the "Too many requests" banner is showing as expected on production. Once we have the PR merged, we can go back to rotating multiple iOS snippets per country.

Comment 7

[Giorgos Logiotatidis [:giorgos]]

(In reply to Cory Price [:ckprice] from comment #3)
> (In reply to Paul [:pmac] McLanahan from comment #2)
> > This must be due to basket's occasional slow response time, which I'm still
> > trying to track down.
> I'd like to blame it on this, but I really don't think this is it. The
> network logs are showing a response coming back very quickly.

For the record I get 7+ seconds response time when POSTing to /news/subscribe_sms/

Comment 8

[Giorgos Logiotatidis [:giorgos]]

I verified that the snippet now sends one request per click and updated the template on production

Comment 9

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Opened https://github.com/mozilla/snippets/pull/62 to disable the "Send" button after it's clicked and before basket sends a response.

I'm seeing 7-10 second response times on my end now as well (both email and SMS). :pmac, let me know if I should open a bug

Comment 10

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Opened bug 1224624 to address response times. I'm going to close this one.