When calling https://graph.microsoft.com/v1.0/teams/{id}/channels/{id}/messages/delta endpoint, I am getting a `400 (Bad Request) response.
I am experiencing the same issue in Microsoft Graph Explorer even after providing Admin Consent.
Below are some relevant posts I found where people are experiencing similar issues
https://github.com/microsoftgraph/microsoft-graph-docs/issues/7631
https://learn.microsoft.com/en-us/answers/questions/201576/when-i-call-the-api-to-get-message-list-by-using-d.html
MS Graph - Conversation delta API not working for some channels
However the beta version of the aforementioned endpoint is functioning properly, but the beta version of Graph API is not advisable to be used in a production app.
I just did a test on your problem, and I found that indeed as you said, when the beta version is used, the api call is successful, and when the v1.0 version is used, it reports a 400 error. This is strange because the documentation does not Too much explanation on this. So, I think this is an unknown error, you can report your problem to Microsoft.
Related
In our project we have used NATS (Server-Version 2.1.9) as our message server.
Often we got some error logs in Java Nats Client like:
`ERROR: Subject remapping requires Options.oldRequestStyle() to be set on the Connection`
It comes from io.nats.jnats version 2.8 (nats.client.impl.NatsConnection # deliverReply).
But we don't notice any problem in our system.
So my question is: How can it happen, what does it warn us about, and how can we handle it?
Please see the response to our github issue that addresses this: https://github.com/nats-io/nats.java/issues/424
In short, this is fixed in our 2.9.0 version. I answered in the issue:
We are able to reproduce this under those conditions of re-using messages. I had also seen it intermittently but couldn't quite put my finger on it.
As it turns out, the error message is a misleading anyway. It happens when we can't match the incoming message with the outgoing one / future that made the request. This should actually never happen. Since it was out-of-band (async) there really wasn't much we could do so printing a messages was better than nothing.
The good news is the current 2.9.0-SNAPSHOT has a fix regarding message handling that addresses this problem. Can you try upgrading to 2.9.0-SNAPSHOT and see if this fixes your problem? 2.9.0-SNAPSHOT is stable and backward compatible since it is almost exclusive JetStream additions and improvements.
I was developing Instant triggers for my Integromat app. I finished 2 of them, and when I started the third one, all webhooks stopped working.
I wrote a mail to the support of about the situation and received the answer:
We can see in logs that webhooks fired from our end but your system
returned us error 400 - it means that webhook works on our side but
was not properly received on your servers side.
So why Integromat can answer 400 code? Is it a bug or my mistake? From that moment, I have tried with the new account, but the issue is still there.
Any suggestions?
Judging by the response you received from the 3rd-party tech support, there's an error somewhere in your webhook code.
The first thing I'd check is of course the code directly inside your webhook's Communication tab, but also, if this code is calling any IML functions you wrote, you'll need to double-check that the IML code is not failing as well.
You could create an IML test using the Integromat Apps SDK VS Code plugin to simulate the function call with incoming JSON data (according to the documentation of the service you are implementing) and see if this call results in some kind of an unexpected error.
I'm having an issue with an Analytics API batch request that I am doing, it was working and now it isn't without me changing anything. I know Google are making changes to their batch endpoints and I believe this is what is causing my errors.
https://developers.googleblog.com/2018/03/discontinuing-support-for-json-rpc-and.html
I am using the .NET client library with the AnalyticsService. Having read through the link above I'm fairly certain I've done what is needed for my batching to continue to work.
Here is a screenshot of the .NET instructions
I've upgraded all Google libraries to the latest versions, I've checked the AnalyticsService object and can confirm the BatchURI is no longer the Global HTTP Batch endpoint www.googleapis.com/batch, it is showing as https://www.googleapis.com/batch/analytics/v3, but I am still getting 400 Bad Requests. Is there something else that I am missing, or do I have to wait until the 12th of August when Google say the switch will be complete?
Thanks
Update: I created an issue on GitHub, apparently it is an internal issue, currently waiting for a fix, see here to keep updated:
GitHub Issue on .NET client library
I had an application using the Google Vision API running fine for nearly a year. It wasn't running for a few months and when I ran it recently, it always returned 400 errors. I went to the account settings and noticed my key was gone. I entered a new one and updated my program. However, it still always gets a 400 error. It does so no matter what key I use (valid or not).
I looks like it isn't accepting the key.
Any idea what the issue might be?
Any way to test that a key is valid?
Earlier today, I was able to send snapshots to the Face API and get responses including faceAttributes describing emotion.
I'm using JavaScript via XMLHttpRequest.
Now, though I've not changed the code, I get OK 200 from the API calls, but the responseText and the response properties are both, "[]".
I'd like to troubleshoot to see what I'm doing wrong, but it seems like the only information available in the cognitive services portal relates to quota.
Where should I look for further analytics?
You'll get an empty response if the API does not detect a face in the image or if the image file is too large (>4MB). You can confirm by testing with an image you know previously worked. To get the best results, make sure the face is well-lit and all features are reasonably visible.
Hello from Cognitive Services - Face API Team,
I wonder the problem belongs to one specific image or all API calls?
For a quick check, you can try the image on the online demo [1].
[1] https://azure.microsoft.com/en-us/services/cognitive-services/face/
Unfortunately doing the troubleshooting from the external perspective is quite difficult since you don't get any logs. The most common steps are to try to repro your problem using either the testing console (https://westus.dev.cognitive.microsoft.com/docs/services/563879b61984550e40cbbe8d/operations/563879b61984550f3039523b) or a tool such as curl or Fiddler so that you can see the raw REST request and response.
With one of those tools you can try to change up your request, try to call a different API, make sure there are no additional details being returned in the body or response headers, etc.
If all else fails please open a support incident from the Azure management portal and we can work with you.
We are also working to improve the logging and troubleshooting capabilities, but it may be some time to see improvements in this area.