Muter bugs

[josh]

Yo @mastahyeti

https://github.com/mastahyeti/OctoGAS/blob/92fd24e6b1462da1fb83d83e3eb1975508167785/src/muter.coffee#L33-L34

So I don't actually think getMessagesForThreads is some preload caching magic. It actually returns a nested array of the fetched messages for the threads. Here you just calling it and discarding the result. Then you call thread.getMessages() again every time later.

https://github.com/mastahyeti/OctoGAS/blob/92fd24e6b1462da1fb83d83e3eb1975508167785/src/muter.coffee#L73-L78

Second, I don't think unmute works. Mute is a special "non-user" label that you would have to remove some how. Unfortunately the current api won't let you get it from getUserLabelByName. So theres basically no way to remove it. The same goes with the new "Social" and "Promotions" labels. Its still all private APIs for now. Definitely check your label:mute query. If theres like hundreds of messages, then your script is still trying to process those every run. That could probably be an API limit issue.

I've started working on my own that uses a magic folder rather than the native mute https://github.com/josh/list-unsubscribe/blob/gas/Code.gs. Just my preference since that works on Mail.app on the iPhone.

[btoews]

When I added getMessagesForThreads it significantly speeded up the script. If that's no longer the case, they might have changed their implementation of the function.

Hmmm. The label:mute thing must have changed, because that used to work. I'll see about finding another solution for that. Using the actual mute feature is nice, because there is a keyboard shortcut for it in the web ui.

[btoews]

I tested the getMessagesForThreads thing with this script:

QUERY = "in:inbox AND ( from:\"notifications@github.com\" OR from:\"noreply@github.com\" )";

function getMessages(preload) {
  threads = GmailApp.search(QUERY);

  if (preload) {
    GmailApp.getMessagesForThreads(threads);
  }

  for (i = 0; i < threads.length; i++) {
    Logger.log(threads[i].getMessages());
  }
}

function main() {
  getMessages(1)
}

When I preload the messages, the average execution time for the script is ~0.5 seconds. When I don't preload the messages, the execution time is ~5 seconds. Seems to help quite a bit.

[btoews]

Second, I don't think unmute works. Mute is a special "non-user" label that you would have to remove some how. Unfortunately the current api won't let you get it from getUserLabelByName. So theres basically no way to remove it. The same goes with the new "Social" and "Promotions" labels. Its still all private APIs for now. Definitely check your label:mute query. If theres like hundreds of messages, then your script is still trying to process those every run. That could probably be an API limit issue.

Yep. I validated this. I had been getting around this by moving the thread to the archive to unmute it. This no longer works. My new hack to fix this is to move the thread to the inbox and then move it to the archive. We'll see how soon this breaks. That change is in https://github.com/mastahyeti/OctoGAS/pull/11

I've started working on my own that uses a magic folder rather than the native mute https://github.com/josh/list-unsubscribe/blob/gas/Code.gs. Just my preference since that works on Mail.app on the iPhone.

Makes sense. I use the Gmail app on my phone, which allows me to mute threads.

[josh]

Tangential, the another change I've made to my script for performance setting up a special "Queue" label to ensure messages are only processed once.

If I want to possibly filter or label a message, I setup a builtin filter that "Skips Inbox, and applies label Queue". I'll do this for any github email. Then my scripts only query the single Queue label and remove that label once its processed the thread.

Querying in:inbox threads over and over lead to so many rate limiting issues. I haven't any problems running this "Process queue" script every 5 minutes.

Just some ideas!

[btoews]

I thought about doing something like that. My own workflow is to archive emails once i've dealt with them. This means that the search only ever returns ~10 results and doesn't run into rate limit problems. That's a good idea to use the gmail filtering though. I'll think about it some more.