account-polld does not recognize when messages are cleared using the "Clear all" button

[Niklas Wenzel]

After each reboot, account-polld stops showing incoming emails after displaying 3 notifications.
The reason for that is that account-polld does not recognize when messages are cleared from the messaging indicator and therefore does not show any further notifications.

How to reproduce:

1) Reboot your phone.
2) Send yourself 3 test emails
3) Wait 5 minutes until account-polld has been run
4) You'll see three notifications stating that there are new emails
5) Tap on the "clear all" entry in the notifications indicator
6) Mark your last three emails as read (this is optional)
7) Send yourself another test email
8) Wait 5 minutes again until account-polld has been run
9) No notification about the new unread email is shown

Why does it happen:

When clicking the "clear all" button, the internal cache of previous messages isn't cleared. Therefore, account-polld still thinks that there are 3 notifications and does not display any further messages.

Log: http://paste.ubuntu.com/10664183/
Old one: http://paste.ubuntu.com/10634045/

[John Lenton (chipaca)]

I don't think this is a bug in account-polld; polld queries the push notifications client to ask about what is displayed. The push notifications client polls the messaging menu to know when things have been cleared from it. That poll is done every 5 minutes, which is the same frequency account-polld is woken, so in actual operation this should not be a problem. You're only seeing this because you're poking polld manually.

[John Lenton (chipaca)]

The 5 minutes interval between polling the messaging menu is not a configuration option, so you'd have to change cleanupLoopDuration in messaging/messaging.go and recompile push to check this.

[Niklas Wenzel (nikwen)]

Thank you very much for your reply, John.

While your explanation makes sense, I have to add that I also see this behaviour in "actual operation". I just added those manual pokes to the description to make reproduction easier but it looks like that was misleading.
When looking at the account-polld logs on my phone during regular usage, I see exactly the same error messages (vivid-proposed, r140). Therefore, no more than 3 incoming messages are displayed for me.

Judging from what you said, it might be a indicator-messaging bug so I'm adding that to the affected projects. Additionally, I'll update the description and remove the parts about poking account-polld manually.

[John Lenton (chipaca)]

There aren't any error messages in what you pasted; could you paste the log from a non-manually-initiated run that exhibits this please?

[Niklas Wenzel (nikwen)]

I'm sorry for my wording. With error messages I meant the lines which state that the notifications are still there, which they clearly aren't.

I'll attach a proper log. I just rebooted my phone to follow the reproduction steps from above.

[Niklas Wenzel (nikwen)]

Here's the new log: http://paste.ubuntu.com/10664183/

[Niklas Wenzel (nikwen)]

I did a bit more debugging here and found out the root cause for this issue. It's somewhere in the communication between account-polld and the ubuntu-push-client.

account-polld's postOffice() method fires off some dbus calls which the ubuntu-push-client responds to with an error message:

2015/04/10 14:47:40.406499 ERROR WatchMethod: ListPersistent(/com/ubuntu/Postal/4, []interface {}{"com.ubuntu.developer.webapps.webapp-gmail_webapp-gmail"}, []interface {}{(*service.DBusService)(0x93ef6000)}) failure: &errors.errorString{s:"package must be prefix of app id"}

The dbus call can be replicated using the following command and results in exactly the same error message:

gdbus call --session \
    -d com.ubuntu.Postal \
    -o /com/ubuntu/Postal/4 \
    -m com.ubuntu.Postal.ListPersistent \
    com.ubuntu.developer.webapps.webapp-gmail_webapp-gmail

So this has probably nothing to do with the indicator-messages project.

[Niklas Wenzel (nikwen)]

Hm, I'll have to go through it again. I just noticed that the log output I posted in my last comment was created by my manually run dbus command and not by the service itself.

[Niklas Wenzel (nikwen)]

Running the following approves that it is indeed no bug in account-polld:

gdbus call --session \
-d com.ubuntu.Postal \
-o /com/ubuntu/Postal/com_2eubuntu_2edeveloper_2ewebapps_2ewebapp_2dgmail \
-m com.ubuntu.Postal.ListPersistent \
"com.ubuntu.developer.webapps.webapp-gmail_webapp-gmail"

This always returns what account-polld sees as well.

[Niklas Wenzel (nikwen)]

I've done more research and the call to cNotificationExists() in messaging.go (ubuntu-push) seems to return the wrong values.

[Niklas Wenzel (nikwen)]

Looking at the recent changes in indicator-messages, I believe this is related either to https://code.launchpad.net/~ted/indicator-messages/lp1385331-unescape-message-ids/+merge/250235 or https://code.launchpad.net/~larsu/indicator-messages/lp1386584/+merge/240773. The latter has some complaints about the "Clear all" button in the MP discussion.

[Niklas Wenzel (nikwen)]

Ok, went back to indicator-messages revision 432 and everything works fine. So some changes since then must have caused the issue.

I'll look deeper into that soon. :)

[Niklas Wenzel (nikwen)]

Ok, I just gave r433 a go and it didn't work. Therefore, we now know that the commit which broke this was r433.

[Niklas Wenzel (nikwen)]

Found the issue!

There's no unescaping being done in im_application_list_remove_all() in im-application-list.c.

Will fix that.

[Niklas Wenzel (nikwen)]

Looks like my last assumption was wrong. However, I found out that g_hash_table_remove() fails in messaging_menu_app_remove_message_internal(), which is invoked by messaging_menu_app_dismiss().

[Niklas Wenzel (nikwen)]

This seems to be caused by the escaping:

Notification ID in ubuntu-push: 57000805-95b1-46e6-aff8-b110fd5cd3d5
Notification ID which is passed to messaging_menu_app_remove_message_internal(): 57000805-2d95b1-2d46e6-2daff8-2db110fd5cd3d5

[Niklas Wenzel (nikwen)]

Ok, I have a fix for this. :)

It can (together with lots of debug code) be found at https://code.launchpad.net/~nikwen/indicator-messages/clear-messages-fix-debug.
I'll further test that fix tomorrow and create a new clean branch with the fix only if it works. :)

[Niklas Wenzel (nikwen)]

MP can be found here: https://code.launchpad.net/~nikwen/indicator-messages/clear-all-unescape-fix/+merge/257471 :)

[Launchpad Janitor (janitor)]

This bug was fixed in the package indicator-messages - 13.10.1+15.10.20150505-0ubuntu1

---------------
indicator-messages (13.10.1+15.10.20150505-0ubuntu1) wily; urgency=medium

  [ Lars Uebernickel ]
  * application list: update root action unconditionally

  [ Niklas Wenzel ]
  * Unescape action names when passing them to the proxy in
    im_application_list_remove_all() (LP: #1434521)

 -- CI Train Bot <email address hidden> Tue, 05 May 2015 16:47:43 +0000