Problems with pulling OneDrive/SharePoint Permissions - node.js

I am currently writing a script in nodejs to pull all DriveItems from the MS Graph API, the idea is to grab the permissions of each DriveItem so that a record can be kept and presented to the user. Our authentication with Graph is app based.
I am running asynchronous requests to MS graph which obviously results in a lot of simultaneous requests. After a few seconds of executing the script, MS graph starts returning the following errors from the endpoint and doesn't seem to recover. The status codes are a 500 internal server error, 504 gateway timeout, and 404 not found.
The number of errors returned isn't always the same; one request returns 856 failed requests, another returns 900.
Here are the different responses received from endpoints which represent true drives and driveitems:
Endpoint: https://graph.microsoft.com/v1.0/drives/(drive_id)/items/(driveitem_id)/permissions
500 Internal server error:
{
"error": {
"code": "-2146232060, Microsoft.SharePoint.SPException",
"message": "Exception from HRESULT: 0x80131904",
"innerError": {
"request-id": "794863b8-bbf1-4866-9604-f8fcec4afabe",
"date": "2016-11-18T05:41:35"
}
}
}
504 Gateway timeout:
{
"error": {
"code": "UnknownError",
"message": "",
"innerError": {
"request-id": "e91c3037-10b6-4523-88d3-7fc31107b719",
"date": "2016-11-18T05:46:21"
}
}
}
404 Not found error:
{
"error": {
"code": "itemNotFound",
"message": "The resource could not be found.",
"innerError": {
"request-id": "b9a8286d-ce8c-4353-b8f0-818fe0f609ea",
"date": "2016-11-18T05:41:35"
}
}
}
This errors occur for a period of time and then everything seems to work fine again.
I can confirm that these endpoints work fine when I use postman to get an individual endpoint and the same token as the script - it returns valid data. Also if I make the script synchronous, it works fine but this is not an acceptable solution as it is far too slow to process the thousands of files I am dealing with.
The only thing I can think of that would be a problem is the sheer amount of simultaneous requests happening? However I am not receiving a 429 too many requests error back from msgraph before this starts to happen.
Any help is greatly appreciated.

Related

PouchDB over HTTP disconnects on inactivity after some minutes?

I am trying to create an application that uses PouchDB as an adapter to a CouchDB running on a server.
Problem: After some minutes of inactivity I get the following error on trying to access the database again:
{
"error": "unauthorized",
"reason": "You are not authorized to access this db.",
"status": 401,
"name": "unauthorized",
"message": "You are not authorized to access this db.",
"docId": "category:aktien"
}
My feeling is, that the HTTP-Connection between Pouch and Couch has a timeout... what can I do about that?
I cant find a "signal" that informs me about the timeout, so I could reconnect. Is there any?
Best Regards,
Tobias
In the settings of CouchDB you can set the session timeout... default is 10 minutes (600 s).

I get Bad Request every time i try to create an azure function

I'm still new in Azure.
Today, I try to create an azure function instance
but, everytime I try to create one I get a Bad Request Error
{
"status": "Failed",
"error": {
"code": "BadRequest",
"message": "Cannot update the site '{project-name}' because it uses x64 worker process which is not allowed in the target compute mode.",
"details": [
{
"message": "Cannot update the site '{project-name}' because it uses x64 worker process which is not allowed in the target compute mode."
},
{
"code": "BadRequest"
},
{}
]
}
}
I have no idea what it does mean. So, can you give me an Idea what's wrong? and How I supposed to do to fix it?.
The Free/Shared tiers only support 32-bit application architecture. You'll need Basic or higher to use 64-bit.

DataFactory Debug Error - BadRequest - factory is deleted

I am creating a pipeline that only runs a simple "wait ", just for testing, because I am trying to understand why my others pipeline are returning errors (the same error).
When I try to debug, it sends the following error:
{
"code": "BadRequest",
"message": "Operation could not be completed as factory is deleted",
"target": "pipeline/Teste_ParaApagar/runid/f0e412a9-21a2-4d0f-ab28-c0287a484326",
"details": null,
"error": null
}
I searched everywhere, I canĀ“t find answer. Can you please help?
I think this is not a common error.
According to the policy, I think you should check your account to see if your ADF was disabled.

Logic Apps "Get file Content" Sharepoint connector timed out for files over 20MB

As the topic implies, my logic app having a Get File Content from a sharepoint connector,which was working fine for all the files less than 20 MB. For the files greater than 20 MB getting timeout after 4 retries by giving the 500 Internal Server Error
I couldn't able to find this type of size limitations in the documentations.
I tried to use the chunks options but its only for upload not for retrieve
Some Other findings :
A file with 17 MB got succeeded at the second retry, however for files more than 20 MB it always getting failed even after 4 retries.
RAW Output:
{
"error": {
"code": 500,
"source": "logic-apis-northeurope.azure-apim.net",
"clientRequestId": "3a0bf64d-2b82-4aef-92ba-ff8b101e44bb",
"message": "BadGateway",
"innerError": {
"status": 500,
"message": "Request timed out. Try again later.\r\nclientRequestId: 3a0bf64d-2b82-4aef-92ba-ff8b101e44bb\r\nserviceRequestId: e0ce569f-96aa-d08b-1c7e-20a6ccf358c3",
"source": "https://xxxxx",
"errors": []
}
}
}
P.S I'm using on-prem sharepoint, i.e gateway is already using. However no timeout logs in the gateway,which makes me to eliminate the issue is not from gateway and from logic app
We can see logic app supports get data from sharepoint according to the on-premises data gateway in this document.
Then click limits on their payload size, we can see the limits of it.
Although the document above doesn't mention the limit of 20 MB for the data response, but I think when you request the data of 17 MB, it beyond exceed the limit. So it got succeeded at the second retry but not success at the first time.

Azure API Manager POST Request/Response Limit 65,535

I have an Application API wrapped in API Manager on Azure cloud service. For whatever reason when I send in a JSON payload of 1000 records or more (which translates to around 200k chars) the request is dropped. No trace, no logging just dropped but if I truncate the payload everything works as expected. If I send the same 1000 record payload into the underlying service (not through API Manager) all works as expected. Is there a request or return size limit when using APIM?
My underlying service was matching inner response codes and applying to overall return code if they were the same. My inner codes were all 404 "item not found". Azure API manager treats a 404 as an error and drops large payloads. This is per their support. On a small return payload it will return a code of 404 and the message but on a large payload it is dropped. Reason I was trying to return 404 is because each record in the return payload contains a status. If the status is mixed return 207 for mixed status but if they are all the same - 200 for found and 404 for not found the overall service was returning the internal status as the overall status. This was bad design. My payload consisted of a search for items that did not exist in the DB and therefore was returning 404 as overall status with messages for each record indicating "Not found". APIM was dropping the return response in favor of a generic 404 url not found response. Switched the internal service to return only 200 or 207 depending on outcome and all is right.
{
"ProcessId": "2",
"Code": 404,
"Message": "Could not resolve token.",
"Token": "#!!!#xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
{
"ProcessId": "2",
"Code": 404,
"Message": "Could not resolve token.",
"Token": "#!!!#xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
Overall return code was set to 404 and APIM dropped the response. I fixed this by setting overall return code to 200 in this case.

Resources