I am using Gmail push notifications for email processing. When I receive a message notification from Google, I use the history list API with the previously stored historyId and can see new messages using messagesAdded. Once I have retrieved the messages, I store the last historyId for the next request.
When testing, if I send two mail messages (about 30 seconds apart) to the watched mailbox, I see two messages notifications from Google and when I call the history API for each of the notifications I see the message ids. This is all good.
If I repeat the same test but send the two mail messages immediately after each other, I get the two notifications from Google but when I call the history API for the first message, I get the two message ids in that history API call. When I call the history API call for the second notification, I get a duplicate of the last message id.
How can I prevent seeing duplicate message ids in this scenario? Any help or pointers would be much appreciated.
Updated: Added request and response example for second test.
I noticed in the response from the Google History API a historyId showing the latest messages that have been processed. If I store this value as the next start point instead of the historyId sent in the notification message, it works around the duplicate issue as on the second request there are no more messages. Not sure if this is the right way to do this as it means I don't store or use the historyId sent in the notification message.
Related
I'm building a messaging integration with Slack and a client. I need to show the badges on the corresponding conversations when the users logs in to the client to show the client how many unread messages it has.
I know that the channels.history method had the unreads parameter which would return as part of the response the amount of unread messages according to the user token, but that method is deprecated and my app is too new to use it.
I'm using the conversations.history now to retrieve the messages which is what slack suggest to use instead of the deprecated method channel.history, but this new method doesn't have that parameter and doesn't show any info regarding the amount of unread messages in the conversation.
As my app is a new one and not a classic one, I cannot use the RTM API.
I'm also subscribed to the message events so that I know when a new message was posted.
My issue is that I need to know how many new messages were sent to the user while he was not logged in.
Is there any way to get that info?
Unread count is in conversations.info method, not in conversations.history. There in unread_count and unread_count_display property in reponse. Documentation is here.
I have tried to send MS Teams bot message request via rest api:
End point: https://smba.trafficmanager.net/ca/apis/v3/conversations/{conversation id}/activities
{"text":"test","type":"message"}
And got empty response:
{}
The message i sent did not appear in the conversation.
Any idea where i could have misconfigured?
It is possible that trustServiceUrl needs to be run before a message is sent, i can't find equivalent rest api to call.
You definitely do need call trustServiceUrl before sending the message. In addition, you need to have additional properties on your activity, like the destination user or tenant id. Please refer to the documents on this, and good starting places are here and here.
Whenever my app posts ephemeral message to Slack channel (in response to a query by a user), I am unable to get the timestamp of my Slack app response. As I want to delete it once the user has made a selection using one of the buttons. Although I have subscribed to 'message.channels' event, I don't get a notification to my app whenever my app posts in the channel (in response to the user input), therefore, I am unable to get the timestamp of the message which I'll use to delete it. All I want is the timestamp of the message posted by my app so that I can delete it but I am unable to receive the timestamp. Please help!
For e.g. in Giphy app for Slack. Let's say the user invokes the app by calling '/giphy [dog]' where 'dog' is just an example of a search term. The app responds by sending a gif and user can either send it, shuffle to the next one or cancel it. I want a similar capability of cancelling the app response but I need the timestamp of the message in order to do so therefore I am asking for help.
Thanks.
Your approach can not work, because Slack is handling ephemeral messages differently from "normal" messages. They are only visible by one user and can not be modified by API methods (e.g. deletion).
But of course its possible to replace ephemeral messages. Here is how:
Your app can just reply to the interactive message request from Slack with a new message. That new message will by default override the original message including ephemeral messages.
You can reply in two ways:
Directly reply to the request from Slack with a message within 3 seconds
Send a message to the response_url from the Slack request within 30 minutes.
See here for the official documentation on how to respond to interactive messages.
This approach works both with interactive messages and slash commands.
See also this answer for a similar situation.
If I make a request to the gmail API for Users.messages.list it will return 100 of the newest messages.
If I make another request, 1 minute later and there are no new emails it will return the same 100 most recent messages.
If I make a third request, 2 minutes after the original and there is a reply to one of the 100 most recent messages it will still return the 100 most recent messages.
The problem with this is the it only returns the message id and thread id, not if there is a new reply or not. That would mean that I would have to check every message that I have locally stored, or every one of the 100 returned messages just to know if there was a reply to it or not.
The way that works, you couldn't "check" your email via the api because if you had stored 10000 messages and you were checking replies on all of them you would use up your entire API "number of requests" allocation in a single day!
What's wrong with you Google?
Sure I could use pop3 or imap but why when I could just use something like /list_recent?
You should definitely take a look at this part of the Gmail API documentation: https://developers.google.com/gmail/api/guides/push
Basically, it explains you how you can setup a "watch" over a Gmail account and receive notifications (new e-mail, deleted e-mail, labels added...) through Pub/Sub, the messaging queue protocol from Google.
The notifications will contain an historyId, which is a kind of milestone in the Gmail account. Using the /history endpoint, you'll then get the e-mails that were added and/or deleted since this history point. You have to store the latest historyId you handled somewhere in your app, so that you can query the right changes (and not miss anything) on the next notification.
If you don't need to react to changes in real-time, maybe you can call the /history endpoint periodically, but it will definitely be less efficient at scale.
It takes a bit of work to get this working but at the end of the day you get a very efficient system able to react about changes in real-time.
I subscribed to Outlook Push Notification Services, precisely I want to receive push notifications for sentitems.
Consequently, I use https://outlook.office.com/api/v2.0/me/MailFolders/sentitems/messages as Resource in my #Microsoft.OutlookServices.PushSubscription POST request to the url https://outlook.office.com/api/v2.0/me/subscription
As expected, I receive the push notification when I send an email. The problem lies in the fact that the ResourceData is always the same. The Id never changes and correspond to the one I received after the first Notification.
I also remarked that even when no mail is sent I keep receiving notification with "ChangeType":"Created" (and always the same ResourceData.Id).
This may be a bug, or should I send back something to the subscriptions after receiving a notification?
This is because the webhook responded to the push notification request with status code 500. Hence Outlook Push Notification Services treated this request as failed and then retried it later for several times. As the notifications of the same subscription are processed in sequence, later notification won't be sent until the earlier notification was successfully sent out. That's why you saw multiple notifications with the same resource data and change type even when no change happened.