I am leveraging Gmail push notification (using StreamingPull) to see if we can keep a near real-time sync with the User’s Gmail inbox.
Occasionally, I see a big gap between updates for some users. For example, my system retrieved pub/sub message (update) for user A with history ID = 10_000, and we don’t see any pub/sub messages for User A until like 30 minutes later with history ID = 10_500, and there were a number of updates in between that happened within that 30 minutes window. But, for some reasons, it doesn’t look like those updates were published to Gmail pub/sub that I am subscribed to.
When I look at Pub/Sub metrics, I don’t see any unacked / backlogged messages, and that’s why I am suspecting those updates are not being published at all.
Is it something that is expected? I am aware that there’s a max notification rate for Gmail update notification, but don’t think the user was anywhere near it. I see the section regarding reliability noting that updates can be dropped / delayed in extreme situations (ref), but such delays were happening bit too frequently vs. only happening in an extreme situation, so I wanted to ensure that I didn’t misconfigure anything…
Is the best solution here leveraging regular polling of history.list
API? OR is there way for me to triage and find some other solutions that will allow me to rely mainly (if not solely) on Gmail push notification for Gmail updates? (I don’t want to get rate limited by Gmail for calling history API too many times).
Thank you for your time and help in advance!
Expectation: Gmail Pub/Sub to publish updates within few seconds or even minute or two after the update reliably (over 99% of the time).
Triaging:
- Looked at Pub/Sub metric
- oldest unacked message: 0
- acked latency: < 500 ms (99.99% of the time)
- unacked messages by region: 0 for all (occassional jump to 1 or so, drops down pretty much immediately)
- Ack / Sent / Publish rate about the same
- Played around with the SubscriberOptions – mainly FlowControl and BatchOption to ensure that we are pulling messages at a reasonable rate and not dropping any messages
Luke Lee is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.