We've got reports that sometimes actionable messages are not displayed correctly by some clients. It doesn't matter if they message is displayed on Outlook OWA or Outlook Desktop app.
I asked one of the clients to install Actionable Message debugger app and check the diagnostics section and others. Here are some details I've managed to read off from it:
No card is attached to this message.
Actionable messages processing has not been performed on this message. Actionable messages are only enabled for Office 365.
Adaptive card payload found but could not be parsed. Please validate the payload.
And diagnostics section:
"CardEnabledForMessage": false,
"ClientName": "OutlookWebApp",
"ClientVersion": "16.2528.7.2602797",
"InternetMessageId": "<ID>",
"Error": "EntityDocument does not exist.",
-
"AdaptiveCardPayload": {
"found": true,
"type": "AdaptiveCard"
},
-
"MessageCardPayload": {
"found": false,
"type": null
},
-
"AuthHeader": {
"results": "<address>; dkim=none (message not signed) header.d=none;<address>; dmarc=none action=none header.from=<address>;",
"authAs": "Internal"
}
Up until recently, I wasn't able to reproduce the issue on my end. During some tests, I've sent myself a test message and it has not been parsed correctly.
When I sent another test message afterwards, it was working perfectly fine.
Of course after comparison of both messages' sources yielded that both sources were identical. Headers were a little different but mostly in time and what appears to be the server. Diagnostics and error sections from debugger are almost identical.
The method we use is SMTP (there were some issues with EWS) and we're thinking of switching back if that causes the issue.
Is there something that can be done in regards to this issue? It's probably worth noting that the payload we send is quite 'heavy' (as in, we had to limit ourselves with the amount of data we send because we were hitting something what looked like size limit)
Changing the script slightly makes the messages render for some users. Others had to wait some time (possibly for some OWA update?) for them to work.
So in the end nothing has been changed and it started working after some time.
Related
We've been doing some testing with the RDC endpoints in Banno and noticed a bizzare issue where, intermittently, a POST request will respond with a 400. Seconds later, submitting the same request will yield a new RDC account as expected. I'm doing my testing in PowerShell, and below are some examples.
New-RDCAccount -userId $userId -accountTypeMarker Checking -name "Text" -accountNumber "XXXXXXXXX"
And the response for this would work, however when I send a request minutes later:
New-RDCAccount -userId $userId -accountTypeMarker Checking -name "Text" -accountNumber "XXXXXXXXX"
#Note that $userId is the same throughout each request
I get this response: The remote server returned an error: (400) Bad Request.
I understand that the error code implies that my body is malformed, but how is it possible that in one request it's acceptable and in the next it's malformed?
Below is the body for each request (with redacted information). The first one is a working example, and the second one is the failed example:
{
"accountNumber": "XXXXXXXX",
"accountTypeMarker": "Checking",
"name": "Text"
}
{
"accountNumber": "XXXXXXXX",
"accountTypeMarker": "Checking",
"name": "Text"
}
Because I feel this issue is a little hard to believe, I've provided screenshots as well with this.
Not working:
Working:
I'm hopeful someone here can help me out here, cause I feel like I'm taking crazy pills looking at this.
Thank you!
Edit:
Here's another example of it working on one instance, and not another with 0 changes to the code (side by side):
Edit of edit:
I can replicate this issue pretty consistently through Banno People AND my own PowerShell script. I feel this is definitely something on the Banno side at this point...
Pictures for Jamies comment:
Working request headers:
Fail request headers (Note that accessing any of the elements yield a null result):
I'm using this endpoint: https://jackhenry.dev/open-api-docs/admin-api/api-reference/v0/rdc/details/#/User%20RDC%20Endpoints/post_a_mobile_api_v0_institutions__institutionId__users__userId__rdcAccounts
I am trying to make a simple python script that posts a text message to a facebook page using requests.
I actually managed to succeed this feat, however, when I add the same logic to a bigger project of mine, a certain request returns a different json.
According to this page https://developers.facebook.com/docs/pages/access-tokens I can exchange the short lived user token I generate in the graph explorer tool for a long lived one that lasts 60 days. This worked for me until now. When I run the same functions, same variables on another .py file that includes other logic as well the request does not return this line:
"expires_in": SECONDS-UNTIL-TOKEN-EXPIRES
And of course later on if I continue the logic and use the token it returns (which is the same) for, let's say, a make_post function the request prints
{'error': {'message': '(#200) If posting to a group, requires app being installed in the group, and \\\n either publish_to_groups permission with user token, or both manage_pages \\\n and publish_pages permission with page token; If posting to a page, \\\n requires both manage_pages and publish_pages as an admin with \\\n sufficient administrative permission', 'type': 'OAuthException', 'code': 200, 'fbtrace_id': 'AqYMMeOcOniWAGgEEtsEURs'}
Why does it not successfully return, the user token had not expired and it has the requires rights. Furthermore I tested this in a smaller .py file and it worked.
Another thing I found out here https://developers.facebook.com/support/bugs/523165725596520/?join_id=f1ff8392b49675c here is that other people have actually reported the same issue but it has been closed as 'intended by design' however there is no information of a solution.
Running the request in my browser also does not work correctly.
Do you have any ideas? I am completely clueless.
Thank you very much in advance
As #CBroe in a comment said, the expires_in didn't have anything to do with my error. The token it returns if valid. The issue I had later on had to do with the url I was parsing
I have multiple subscriptions to different entities, and at some random time one of the subscriptions stops being notified.
This is because the lastNotification attribute is set in the future. Here is an example :
curl 'http://localhost:1026/v2/subscriptions/xxxxxxxxxxxxxxx'
{
"id": "xxxxxxxxxxxxxxx",
...
"status": "active",
...
"notification": {
"timesSent": 1316413,
"lastNotification": "2021-01-20T18:33:39.000Z",
...
"lastFailure": "2021-01-18T12:11:26.000Z",
"lastFailureReason": "Timeout was reached",
"lastSuccess": "2021-01-20T17:12:09.000Z",
"lastSuccessCode": 204
}
}
In this example, lastNotification is ahead of time. It is not until 2021-01-20T18: 33: 39.000Z for the subscription to be notified again.
I tried to modify lastNotification in the mongo database but that does not change it. Looks like the value 2021-01-20T18: 33: 39.000Z is cached.
The field lastFailureReason specifies the reason of the last notification failure associated to that subscription. The diagnose notification reception problems section in the documentation explains possible causes for "Timeout was reached". It makes sense to have this fail randomly if your network connection is somehow unstable.
With regards to timestamping in the future (no matter if it happens for lastNotification, lastFailure or lastSuccess) is pretty weird and probably not associated to Orion Context Broker operation. Orion takes timestamp from internal clock of the system where it is running, so maybe your system clock is set in the future.
Except if you run Orion Context Broker with -noCache (which in general is not recommended), subscriptions are cached. Thus, if you "hack" them in the DB you will not see the effect until next cache refresh (refreshes takes place at regular intervals, defined by -subCacheIval parameter).
What format should I return the response to the API user if an error occurred? Just return the response as a status code and error message:
Full authentication is required to access this resource
(the status 401 was returned)
Or it is better to return it in this format:
{
"timestamp": "2020-06-14T21:20:52.941+0000",
"status": 401,
"error": "Unauthorized",
"message": "Full authentication is required to access this resource",
"path": "/api/users/me"
}
Well, it depends:
If you know your front end urgently requires the direct message of the error, ignoring anything else, then going for the short and direct to the point answer might be your best choice.
But honestly, if experience in programming has taught me anything, is that the more information you have about something, the better, ESPECIALLY IF IT'S an ERROR!!! With the longer response, you have many more tools in you hand, both for giving the final user a better look of your application - You can present for the user a small title, a detailed message and, for example, use an internal code to show a red "error" box if a fatal error ocurred or a "warning" yellow box if a validation simply failed - and especially for the dev to solve that problem (The final user might never see the "timestamp", "status", "path" or stacktrace of the error - He shouldn't... - But it will surely help you track what caused the error).
Take a look at these (1, 2 and 3) articles to help you decide your situation and, if needed, customize your error response structure
I'm trying to test the pass_thread_control function on Facebook Messenger, to have my Dialogflow bot direct ongoing conversation to a human operator. So far I'm stuck at even trying to get a "success" code in Graph API Explorer. I have reviewed Facebook's documentation ( https://developers.facebook.com/docs/messenger-platform/reference/handover-protocol/pass-thread-control/ ), carefully looked through different threads here or elsewhere. I have:
Subscribed my Facebook Page to receive messaging_handovers.
Set the Dialogflow chatbot app as the Primary Receiver.
Set the Page Inbox as Secondary Receiver.
...And I keep on getting various errors. For example, I try this request in Graph API explorer:
POST to https://graph.facebook.com/v5.0/me/pass_thread_control
with params:
{
"recipient": {
"id": "myPageID"
},
"target_app_id": "263902037430900"
}
{
"error": {
"message": "Unsupported post request. Object with ID 'me' does not exist, cannot be loaded due to missing permissions, or does not support this operation. Please read the Graph API documentation at https://developers.facebook.com/docs/graph-api",
"type": "GraphMethodException",
"code": 100,
"error_subcode": 33,
"fbtrace_id": "AipGijCLKQOwOl6L792ZEgG"
}
}
Maybe the issue is the recipient PSID? This is the only parameter I have no idea where to get. What is the page scoped app-id? How do I get it?
Or maybe I missed some permissions...?
Any help getting me unstuck much appreciated...
Okay, I actually managed to figure it out.
First and foremost - I discovered the Page I was trying to pass the thread control to wasn't linked to my Facebook Business account and the chatbot app was. I added the page in Facebook Business Manager so that it's linked to the same business account as the chatbot app. NOTE: I am not sure that this is a prereq for everyone, so take caution. It might not be required in all scenarios.
To retrieve the Page PSID, which can then be used in the 'recipient' param of the POST request to pass_thread_control, Sent a GET request using Graph API Explorer as shown here: https://developers.facebook.com/docs/facebook-login/connecting-accounts#examples
Even though the example request does not contain the appsecret_proof param, I used it and haven't tested the request without it. A very simple way of generating appsecret_proof using PHP is shown here: https://developers.facebook.com/docs/graph-api/securing-requests#generate-proof
Then when providing the PSID obtained using method shown in point 2., I got "success:true" while testing the pass_thread_control, which did pass the thread control to Secondary Receiver = Page Inbox. Yaaay! 😊
All of the above is described also in this thread, which helped me figure it out, so credit to Sunil: Is Facebook Messenger PSID PageScope constant for User