IssueTracker

Before opening a new issue, please search for other related issues, click the ★ to subscribe to updates, and click +1 to vote.

Description

As an application that integrates with the Gmail API as well as other email provider APIs, we interact with a lot of email data to build our features. As such, its important that we ascertain certain truths from email that are not necessarily API specific. Things like id headers such as Message-ID become important when comparing emails that come from various APIs. Thus we lean into the email headers as a source of truth for certain details.

I understand the transition from a draft email to a sent email, where the procedure is to delete the draft and create a new email that is sent version. This is consistent in the API as we will receive payloads sourced from history ID requests that reflect a delete then a create. Having a new Message-ID here is also expected with the delete/create flow.

What's inconsistent here is that as a user is typing a draft, they are effectively updating the same draft over an over, for which we receive multiple payloads from history changes, each reflecting some update to what is supposed to be the same draft. If this were to remain consistent throughout the draft update cycle, then I think it would more accurately reflect reality, that a specific email, identified by the assigned Message-ID is getting repeatedly updated.

I'm looking for any details on the current approach of changing the Message-ID header with each draft save, as well as asking a bold question: Should Gmail reuse the initially assigned Message-ID header for each draft update? With the info I have today, I think the answer should be yes, but would like to learn more.

Steps

• Start with an OAuth connection to a user's gmail account
• Enable Watch, so we get webhooks
• From the gmail web interface, start typing a new draft and keep updating it
• Notice that every time gmail saves the draft, it generates new history activity
• For each history activity, get the underlying message by the api ID, and specifically get the RAW mime payload
• Observe that for each update, the Message-ID header value changes