we have a logic app that takes HTTP requests and creates BLOBs from it.
The last step is the "Create Blob".
We had an incident, where the Create blob timed out
{
"error": {
"code": "BadRequest",
"message": "Http request failed: the server did not respond within the timeout limit. Please see logic app limits at https://aka.ms/logic-apps-limits-and-config#http-limits."
}
}
however it seems the blob was created and then overwritten. This is based on the fact that we have a webhook on this location and it got triggered twice.
I assumed for a short time it was a 0kb blob in the first attempt and then full content, but the webhook processed the content twice correctly.
Afraid to say, there is not that much documentation on the working and issues of Create Blob i can find so hopping anyone encountered similar issue.
Thank you
Related
I am using fetch in a NodeJS application. Technically, I have a ReactJS front-end calling the NodeJS backend (as a proxy), and then the proxy calls out to backend services on a different domain.
However, from logging errors from consumers (I haven't been able to reproduce this issue myself) I see that a lot of these proxy calls (using fetch) throw an error that just says Network Request Failed, which is of no help. Some context:
This only occurs on a subset of all total calls (lets say 5% of traffic)
Users that encounter this error can often make the same call again some time later (next couple minutes/hours/days) and it will go through
From Application Insights, I can see no correlation between browsers, locations, etc
Calls often return fast, like < 100 ms
All calls are HTTPS, non are HTTP
We have a fetch polyfill from fetch-ponyfill that will take over if fetch is not available (Internet Explorer). I did test this package itself and the calls went through fine. I also mentioned that this error does occur on browsers that do support fetch, so I don't think this is the error.
Fetch settings for all requests
Method is set per request, but I've seen it fail on different types (GET, POST, etc)
Mode is set to 'same-origin'. I thought this was odd, since we were sending a request from one domain to another, but I tried to set it differently and it didn't affect anything. Also, why would some requests work for some, but not for others?
Body is set per request, based on the data being sent.
Headers is usually just Accept and Content-Type, both set to JSON.
I have tried researching this topic before, but most posts I found referenced React native applications running on iOS, where you have to set some security permissions in the plist file to allow HTTP requests or something to do with transport security.
I have implement logging specific points for the data in Application Insights, and I can see that fetch() was called, but then() was never reached; it went straight to the .catch(). So it's not even reaching code that parses the request, because apparently no request came back (we then parse the JSON response and call other functions, but like I said, it doesn't even reach this point).
Which is also odd, since the request never comes back, but it fails (often) within 100 ms.
My suspicions:
Some consumers have some sort of add-on for there browser that is messing with the request. Although, I run with uBlock Origin and HTTPS Everywhere and I have not seen this error. I'm not sure what else could be modifying requests that would cause it to immediately fail.
The call goes through, which then reaches an Azure Application Gateway, which might fail for some reason (too many connected clients, not enough ports, etc) and returns a response that immediately fails the fetch call without running the .then() on the response.
For #2, I remember I had traced a network call that failed and returned Network Request Failed: Made it through the proxy -> made it through the Application Gateway -> hit the backend services -> backend services sent a response. I am currently requesting access to backend service logs in order to verify this on some more recent calls (last time I did this, I did it through a screenshare with a backend developer), and hopefully clear up the path back to the client (the ReactJS application). I do remember though that it made it to the backend services successfully.
So I'm honestly not sure what's going on here. Does anyone have any insight?
Based on your excellent description and detective work, it's clear that the problem is between your Node app and the other domain. The other domain is throwing an error and your proxy has no choice but to say that there's an error on the server. That's why it's always throwing a 500-series error, the Network Request Failed error that you're seeing.
It's an intermittent problem, so the error is inconsistent. It's a waste of your time to continue to look at the browser because the problem will have been created beyond that, either in your proxy translating that request or on the remote server. You have to find that error.
Here's what I'd do...
Implement brute-force logging in your Node app. You can use Bunyan, or Winston or just require(fs) and write out to some file when an error occurs. Then look at the results. Only log it out when the response code from the other server is in the 400 or 500 ranges. Log the request object and the response object.
Something like this with Bunyan:
fetch(urlToRemoteServer)
.then(res => res.json())
.then(res => whateverElseYoureDoing(res))
.catch(err => {
// Get the request & response to the remote server
log.info({request: req, response: res, err: err});
});
where the res in this case is the response we just got from the other domain and req is our request to them.
The logs on your Azure server will then have the entire request and response. From this you can find commonalities. and (🤞) the cause of the problem.
I have followed this tutorial and have implemented Microsoft login via OAuth and Azure. Also, I have fetched data from Microsoft Graph to store in my database.
Here is a code sample to fetch data using Microsoft Graph:
$graph = new Graph();
$graph->setAccessToken($accessToken->getToken());
$user = $graph->createRequest('GET', '/me?$select=id,displayName,givenName,surName,mail,mobilePhone,jobTitle,userPrincipalName')
->setReturnType(Model\User::class)
->execute();
The code works fine and I get my desired data.
However, when I change the url from '/me?$select=id,displayName,givenName,surName,mail,mobilePhone,jobTitle,userPrincipalName' to '/me?$select=id,displayName,givenName,surName,mail,mobilePhone,jobTitle,userPrincipalName,mailboxSettings', I am getting this error:-
Error Code:- 400| Error Message:- Client error: `GET https://graph.microsoft.com/v1.0/me?$select=id,displayName,givenName,surName,mail,mobilePhone,jobTitle,userPrincipalName,mailboxSettings` resulted in a `400 Bad Request` response: { "error": { "code": "AuthenticationError", "message": "Error authenticating with resource", "innerErr (truncated...) | Error Location:- Line No. 113 in file C:\xampp7.2\htdocs\kaec\vendor\guzzlehttp\guzzle\src\Exception\RequestException.php
As you can see, I am getting the 400 Bad Request error only when I am adding 'mailboxSetttings' in the query string of the url.
Why am I getting this error? The tutorial itself has used 'mailboxSetttings' in their sample code?
PS: Two days ago, it worked absolutely fine when I used 'mailboxSetttings' in the query. But today, I am getting 400 - Bad Request.
Check if you have MailboxSettings.Read and MailboxSettings.ReadWrite permissions to be able to read, update, create, and delete your mailbox settings.
I agree with #user2250152 answer, at first I used an access token which doesn't with the scope of MailboxSettings.ReadWrite, and I called the api
'https://graph.microsoft.com/v1.0/me?$select=id,displayName,givenName,surName,mail,mobilePhone,jobTitle,userPrincipalName,mailboxSettings'
it returns 403 error(not the same as yours 400), I checked the api document and found that the 'mailboxSettings' property really exists but even I used beta version of the api I still can't find it in response. So I tried to add api permission when generate the access token, finally it worked for me.
I think you can debug your program to check if the access token you used to call the api has the scope of 'MailboxSettings.ReadWrite', just decode the token and you can see it in the claim "scp", because you said that your programs run absolutely fine before. So maybe you've added more other scopes(not belong to graph) when generate access token.
Everything works perfect when I run locally. When I deploy my app on AppEngine, for some reason, the most simple request gets timeout errors. I even implemented retry and, while I made some progress, it still not working well.
I don't think it matter since I don't have the problem running on local, but here's the code I just used for request-retry module:
request({
url: url,
maxAttempts: 5,
retryDelay: 1000, // 1s delay
}, function (error, res, body) {
if (!error && res.statusCode === 200) {
resolve(body);
} else {
console.log(c.red, 'Error getting data from url:', url, c.Reset);
reject(error);
}
});
Any suggestions?
Also, I can see this errors in the Debug:
This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application.
────────────────────
The process handling this request unexpectedly died. This is likely to cause a new process to be used for the next request to your application. (Error code 203)
The error 203 means that Google App Engine detected that the RPC channel has closed unexpectedly and shuts down the instance. The request failure is caused by the instance shutting down.
The other message about a request causing a new process to start in you application is most likely caused by the instances shutting down. This message appears when a new instance starts serving a request. As your instances were dying due to the error 203, new instances were taking its place, serving your new requests and sending that message.
An explaination for why it's working on Google Cloud Engine (or locally) is because the App Engine component causing the error is not present on those environments.
Lastly, if you are still interested in solving the issue with App Engine and are entitled to GCP support, I suggest contacting with the Technical Support team. The issue seems exclusive to App Engine, but I can't answer further about the reason why, that's why I'm suggesting contacting with support. They have more tools available and will be able to help investigate the issue more thoughtfully.
We would like to automatically create a project ID and install our ULAPPH Cloud Desktop application using the App Engine Admin API (REST) and Golang.
https://cloud.google.com/appengine/docs/admin-api/?hl=en_US&_ga=1.265860687.1935695756.1490699302
https://ulapph-public-1.appspot.com/articles?TYPE=ARTICLE&DOC_ID=3&SID=TDSARTL-3
We were able to get a token but when we tried to create a project ID, we get the error below.
[Response OK] Successful connection to Appengine Admin API.
[Token] { "access_token" : "TOKEN_HERE", "expires_in" : 3599, "token_type" : "Bearer" }
[Response Code] 403
[Response Body] { "error": { "code": 403, "message": "Operation not allowed", "status": "PERMISSION_DENIED", "details": [ { "#type": "type.googleapis.com/google.rpc.ResourceInfo", "resourceType": "gae.api", "description": "The \"appengine.applications.create\" permission is required." } ] } }
We are just using the REST API calls. Request for token was successful as you can see above and the scope is ok as well. Now, when we posted the request to create application, we are having the error that says "appengine.application.create" permission required.
How do we specify the permission?
What are the possible reasons why we are getting that error? Do we missed to send a field in JSON or in query?
As per below link, we just need to pass the json containing the id and location. We also just need to pass the token in the Authorization header. The same logic I have used successfully in accessing Youtube, Drive APIs etc so not sure what needs to be done since I have followed the docs available.
I have also posted the same issue in Google Groups and now waiting for their reply.
It seems you've given no details about how you set up the account you're using to authorize the request. You'll need to make sure the appengine.applications.create permission is given to the account you're using, as mentioned in the error text. You can use the Google Identity and Access Management (IAM) API for this.
(by the way, I'd given this answer in the original thread, although you didn't reply or seem to take action on it. check it out! this is likely the solution you need!)
urlopen fails with a 500 code and '{"error_code":1,"error_msg":"An unknown error occurred"}' error from Facebook when posting an Open Graph Action. I can get the code to work with other posts (e.g. posting a comment on a status using the graph API works fine). I can also get this action-post to work using curl. So this seems like a urllib2.urlopen issue when posting a form-data with a URL as one of the values.
Graph api post that works with curl :
curl -F 'access_token=nnnnnn' -F 'object=https://abc.com/123' \
'https://graph.facebook.com/me/namespace:action' -k
Same Graph api post thru urllib2 which gives the error :
from urllib2 import urlopen, Request, URLError
request = Request (url='http://graph.facebook.com/me/namespace:action';,
data = urllib.urlencode(
{'object':'https://abc.com/123',
'access_token':'nnnnnnnn'
},
headers = {'Content-Type': 'application/x-www-form-urlencoded'}
)
response = urlopen (request)
What could I be doing wrong ? (I am new to urllib2.urlopen. Btw, I originally tried urlfetch.fetch thru the urlfetch python module. That did not work either). I am using this thru goole app engine.
After a fair amount of digging/trial-error, finally managed to solve this.
This is not an issue with urllib urlopen, but more of a Google App Engine nuance where when an action post on an open Graph URL is called - it causes Facebook to trigger a 'get' on the Object URL (synchronously).
So essentially the get is being called on app engine app while an active instance is already calling the FB graph URL. I am currently using an unpaid instance and this is causing an unexpected behavior such that FB to fails the OG post (I see the get on the logs going thru successfully, while the active post, so not sure what causes FB to fail - anybody with an insight, please share).
I got around this by 'taskqueue'ing urlopen/OG-action-post - and when this is called the second time (FB apparently caches the object the first time) it succeeds.
If anybody needs more details, get in touch and am more than happy to save you all the time and pain that I have already gone thru..