Can we break discussing this into two very clear camps:
1. Labels update after a Gmail reload (Stick-On-Reload)
2. Labels aren't there after a Gmail reload (Lost-On-Reload)

If there's anyone with #2, I want to speak to you immediately because that's a critical problem.

#1 is just the way new Gmail works. We no longer expected to see immediate updates to the Gmail's label list, after a change in ActiveInbox.

Typically, nudging conversations forward&back (or going back to the inbox and back in) will trigger Gmail to refresh its label list accurately.

It's because we used (AIB6 and earlier) add/remove labels by simulating a user clicking them. This is why you sometimes saw the Labels box flash or even linger. It was as flakey as it sounds.

In new Gmail, this wasn't possible. So we switched to using the official Gmail API to add/remove labels, which is 100% stable (which I'm thrilled about).

But it comes at the expense of disconnecting Gmail's UI from the changes that ActiveInbox makes. We update labels on Gmail's server directly (which is robust), but Gmail's UI doesn't necessarily learn of those changes until it moves conversations (and asks the server), or reloads (again, asking the server).

tl;dr if you're suffering from #1 (Stick-On-Reload)...
Trust that it's ok that Gmail's UI can sometimes be different from ActiveInbox, because they'll reconcile in the end.

I'm trying to think of ways to make this more trustworthy. Here are some to start, based on what happens if there truly is a failure to update the server (because that's the only real cause of lost trust)...
* Log that somewhere you can see, so you have an accurate view of the 'true' state and what you should expect to see. E.g. a button in our Preferences that let's you see that email X has a request to add label Y, but it's not yet on Gmail's server.
* If we can't yet add label Y to your email via Gmail's server (e.g. you're offline), to save the intent to your hard disk, and keep retrying, so it happens eventually (e.g. when you reconnect). We already do this, but I'm going to double check its robustness.

Can we break discussing this into two very clear camps:
1. Labels update after a Gmail reload (Stick-On-Reload)
2. Labels aren't there after a Gmail reload (Lost-On-Reload)

If there's anyone with #2, I want to speak to you immediately because that's a critical problem.

#1 is just the way new Gmail works. We no longer expected to see immediate updates to the Gmail's label list, after a change in ActiveInbox.

Typically, nudging conversations forward&back (or going back to the inbox and back in) will trigger Gmail to refresh its label list accurately.

It's because we used (AIB6 and earlier) add/remove labels by simulating a user clicking them. This is why you sometimes saw the Labels box flash or even linger. It was as flakey as it sounds.

In new Gmail, this wasn't possible. So we switched to using the official Gmail API to add/remove labels, which is 100% stable (which I'm thrilled about).

But it comes at the expense of disconnecting Gmail's UI from the changes that ActiveInbox makes. We update labels on Gmail's server directly (which is robust), but Gmail's UI doesn't necessarily learn of those changes until it moves conversations (and asks the server), or reloads (again, asking the server).

tl;dr if you're suffering from #1 (Stick-On-Reload)...
Trust that it's ok that Gmail's UI can sometimes be different from ActiveInbox, because they'll reconcile in the end.

I'm trying to think of ways to make this more trustworthy. Here are some to start, based on what happens if there truly is a failure to update the server (because that's the only real cause of lost trust)...
* Log that somewhere you can see, so you have an accurate view of the 'true' state and what you should expect to see. E.g. a button in our Preferences that let's you see that email X has a request to add label Y, but it's not yet on Gmail's server.
* If we can't yet add label Y to your email via Gmail's server (e.g. you're offline), to save the intent to your hard disk, and keep retrying, so it happens eventually (e.g. when you reconnect). We already do this, but I'm going to double check its robustness.

Note: the link to this topic from Andy's summary post is incorrect. It is a duplicate of the link to the ZACTIVE topic. I'll post here anyway.

I'll offer one small idea: if there are changes pending for an email, don't bury them in a preferences button. Instead, have them show up on the email in question somewhere. Perhaps a button with a sync icon, where hovering over it clarifies whether changes have been sent to the server, or are pending? Something along those lines?

Andy - this appears to manifest as a pretty bad case for me, as a task was simply lost.

Here's the troubling thing that happened to me just now, in a Gmail tab that was reloaded earlier today. Here are the steps I performed:

1. Postpone an overdue email from within the Radar (Today list view) to a date later this month.
2. Observe the email disappear from the Today list, as it should.
3. Do a search for the email, find that the date labels did not change.
4. Go back to the Inbox, and notice the email back in the Today list.
5. Repeat #1 above. Again, #2 happens, and again #3!
6. Open the email this time, and change the date from within the email.
7. Click on the Inbox. The email is no longer there.
8. Search for the email. Found it, but **the due date has been completely removed!**
9. Restart Gmail. Still, there's no due date. A task has been lost.

Hi,
Every day, I'm having to re-login to my Chrome account, after which I have lost all my customised ActiveInbox labels. Sad! I've been using ActiveInbox for over 7 years now, and this is the first time this has happened. Please help!