Steps to reproduce: 1. With device 1 ask a question 2. Press back button when the question is sent 3. With device 2 answer the question Expected result: Device 1 should get a notification Actual result: Device one doesn't get any notification I've done a little debugging and I've seen that the api for notifications works fine and returns a response with notifications details. However something gets wrong and the app doesn't create the notifications.

It seems that gettext function in https://github.com/mozilla/buddyup/blob/master/app/js/notifications.js#L64 it is not defined for some reason.

Also is seems that something goes wrong with endpoints as in https://github.com/mozilla/buddyup/blob/master/app/js/notifications.js#L37 most of the times the result is false. This leads to push_realtime() function where nothing happens if you are not inside the question and this way user can not get notifications that should get. This maybe is the reason of the strange behavior in the past when notifications didn't appear always in time but in future all together, old and new like in bug 1142155. Forgot to say that the above have been tested on v2.2 FxOS.

PR: https://github.com/mozilla/buddyup/pull/184 Fredy, do the above change fix this problem for you? I'm not set up right not to test notifications.

Unfortunately no, it hasn't changed anything, still seeing the issues of comment 1 and comment 2. In comment 1 case I get this console error: "ReferenceError: gettext is not defined"

I still can't get either the simulator or a device to work, so I still can't test this. Fredy, some other changes have landed on master that could effect this. Can you check those too? The master branch at 33717e78aba29942cc27d496bdb2d437f5e3705f has the changes I'm talking about. If these don't work either, I'm out of ideas. I'll need to get the simulator working reliably or get a device.

I still haven't seen any notifications when testing lately using both the Flame and the Z3 device. I am running https://github.com/mozilla/buddyup/commit/33717e78aba29942cc27d496bdb2d437f5e3705f. Would it be helpful to try to find a regression range for this? I really think we need to escalate this as a blocker with the time we have to left before we will be shipping.

Grabbing this from Mike

From a discussion in irc with Mike for the comment 1 we found that "<script src="js/l10n.js"></script>" should be added in index.html where the notifications.js is defined. So the main issue now is the one I describe in comment 2.

PR: https://github.com/mozilla/buddyup/pull/187

Landed: https://github.com/mozilla/buddyup/commit/043660fb9639dd4ce8710d642145ed47c936ba86

I did some preliminary testing of this with 2 Flames and a Z3, and while I see notifications on the Flame, I don't see them coming through on the Z3. The Z3 is running the dogfood-latest build which is the latest 2.5 build available. I will try to see if something comes up in logcat or console.

Oddly, the next time I tested this, I got a whole bunch of notifications that were queued up at once. Now it appears on the Z3 notifications are showing. fredy said he will perform some testing as well, and will verify if we get consistent results.

Comment from fredy over the weekend: I still don't get notifications either in device or simulator I'll do more tests during the weekend It still seems to be a problem with the endpoints... it seems that the one on my device doesn't agree with the one that gets the notification... So right now it seems QA is not getting consistent results to verify this bug.

As Marcia said in the previous comment, I get an inconsistent behavior. Sometimes I get notifications as I should, sometimes I don't get them at all. Note: Notifications aren't lost, so if user is able to get one then all the past, not shown, notifications show up.

Going to reopen based on fredy's comment - what can QA do to help debug this?

The original problem here was a regression that caused all notifications to fail. That problem is fixed, since Fredy can get any notifications at all. I am very hesitant to blame intermittent failures on BuddyUp. I can't think of a mechanism that would cause notifications to fail sometimes but not others that is in our control. Unfortunately we have no way to test Simple Push or notice errors in it, except in the sending of events (Sumo hasn't reported any errors here lately). All we have is absence of data, and I can't debug that. The original problem here is fixed. I suggest we open another bug if there is a reliably-reproduced problem we suspect is caused by BuddyUp.

Verifying the resolved regression.