Assigned
Status Update
No update yet.
Comments
mi...@maintop.biz
Unfortunately, I see this issue a lot in my Gmail Inbox. Half of the emails in my Gmail inbox should not be there! They were already archived in Superhuman but they still show in Gmail Android app as well as Gmail web app.
ga...@google.com
ga...@google.com
Hi there!
Thank you for reporting this behaviour. I have followed the steps you provided in my test environment but I have been unable to reproduce the behaviour you describe. So that I can look into this further, can you please provide the following information:
- What Operating system version and application are you continuing to see the messages in the INBOX after the labels have been removed?
- Has the Inbox view been refreshed since removing the labels? and if yes:
- Code samples which for listing the messages of a thread and removing the INBOX label from them all, where after execution the mails still appear in the Inbox view
Many thanks!
[Deleted User] <[Deleted User]>
Hi!
I'm glad you're working on this.
1. I'm using Superhuman (https://superhuman.com ) on Chrome, but I can reproduce this over the API.
2. Yes!
3. i=It's below. You'll need to construct an instance of the gmail.Service by providing oauth credentials. The threadID is the API threadID.
My exact steps to reproduce the problem were:
1. Go to Gmail, and snooze a thread until 1 minute from now.
2. Wait for 1 minute
3. Run this function with the thread I just snoozed
4. Refresh Gmail (the thread is still at the top of the inbox)
5. Refresh Superhuman (the thread is now archived)
If it would be helpful for testing, please send me (conrad@superhuman.com) a test Gmail account, and I can whitelist that account for use with Superhuman.
```
package main
import (
"context"
"fmt"
"os"
"google.golang.org/api/gmail/v1 "
)
// archiveThread archives a thread using batchModify to change the labels on individual messages.
func archiveThread(client *gmail.Service, threadID string) error {
thread, err := client.Users.Threads.Get("me", threadID).Format("minimal").Do()
if err != nil {
return err
}
messageIDs := []string{}
for _, msg := range thread.Messages {
messageIDs = append(messageIDs, msg.Id)
}
if len(messageIDs) == 0 {
fmt.Printf("NOTHING TO DO: %#v\n", messageIDs)
return nil
}
err = client.Users.Messages.BatchModify("me", &gmail.BatchModifyMessagesRequest{
Ids: messageIDs,
RemoveLabelIds: []string{"INBOX"},
}).Do()
if err != nil {
return err
}
fmt.Printf("DONE: %#v\n", messageIDs)
return nil
}
```
I'm glad you're working on this.
1. I'm using Superhuman (
2. Yes!
3. i=It's below. You'll need to construct an instance of the gmail.Service by providing oauth credentials. The threadID is the API threadID.
My exact steps to reproduce the problem were:
1. Go to Gmail, and snooze a thread until 1 minute from now.
2. Wait for 1 minute
3. Run this function with the thread I just snoozed
4. Refresh Gmail (the thread is still at the top of the inbox)
5. Refresh Superhuman (the thread is now archived)
If it would be helpful for testing, please send me (conrad@superhuman.com) a test Gmail account, and I can whitelist that account for use with Superhuman.
```
package main
import (
"context"
"fmt"
"os"
"
)
// archiveThread archives a thread using batchModify to change the labels on individual messages.
func archiveThread(client *gmail.Service, threadID string) error {
thread, err := client.Users.Threads.Get("me", threadID).Format("minimal").Do()
if err != nil {
return err
}
messageIDs := []string{}
for _, msg := range thread.Messages {
messageIDs = append(messageIDs, msg.Id)
}
if len(messageIDs) == 0 {
fmt.Printf("NOTHING TO DO: %#v\n", messageIDs)
return nil
}
err = client.Users.Messages.BatchModify("me", &gmail.BatchModifyMessagesRequest{
Ids: messageIDs,
RemoveLabelIds: []string{"INBOX"},
}).Do()
if err != nil {
return err
}
fmt.Printf("DONE: %#v\n", messageIDs)
return nil
}
```
ga...@google.com
Hi there!
Thank you for the additional information. I was able to reproduce the behaviour in my test environment and so have forwarded this internally.
Many thanks!
mi...@maintop.biz
Any updates on this?
br...@bry.net
Any update on this?
ne...@mimestream.com
This seems to happen via IMAP too, so it affects pretty much every email client out there. Seems to also happen with threads.modify, too.
da...@durrans.com
+1 I am affected by this issue. It makes using a third party client in conjunction with the snooze feature very challenging.
cr...@gmail.com
I can confirm that I also experience this bug on the actual Gmail app itself.
ri...@sporedata.com
it's crazy that such an annoying bug has been around for so long. if you archive the email the snoozing is deleted, and so you just can't do anything.
mi...@30a.com
As of today (April 22, 2022), in the Gmail app on my iPhone 13, my "snoozed" emails are showing up in my regular Inbox, even though they are not scheduled to reappear / un-snooze until later this week. Is there any fix for this issue, as keeping my email Inbox decluttered is the whole point of the "snooze" feature. Thank you for any updates or fixes!
da...@gmail.com
+1
me...@connorgurney.me.uk Restricted+
Restricted+
Comment has been deleted.
ma...@smart-life-choices.com
I see this from time to time and would it fixed. 3yrs is along time.
re...@gmail.com
+1
ma...@marsimedia.com
+1
jp...@google.com
mi...@gmail.com
This is still happening with me, and even happens on the Gmail app for iOS itself.
ty...@gmail.com
This just happened for me using the Gmail website on Chrome. 100+ messages that were previously archived have reappeared as "snoozed X time ago".
Description
When you remove the INBOX label from all messages in a conversation that had been snoozed in Gmail, the thread still appears in Gmail's INBOX view.
**What steps will reproduce the problem?**
1. Snooze a conversation in Gmail.
2. Wait until the conversation returns to your Gmail inbox view.
3. Use the API request too (
**What is the expected output? What do you see instead?**
* **Expected:** The thread is no longer in Gmail's INBOX view.
* **Actual:** The thread is still in the INBOX in Gmail.
**Additional Information**
We use /messages/modify instead of /threads/modify to avoid a race-condition where a new email can arrive on the thread between the user viewing it and the modify request reaching the server. This is elongated in our case because we let users process email offline, so the window for a race condition can be many hours long.