Microsoft-graph-docs: New Planner Task error - InternalServerError - Unexpected end when reading token

Created on 15 May 2019  Â·  4Comments  Â·  Source: microsoftgraph/microsoft-graph-docs

Dear all,

I am trying to create a new task in Microsoft Planner through the use of the Office Graph API.
I use this article as a reference: https://docs.microsoft.com/en-us/graph/api/planner-post-tasks?view=graph-rest-1.0&tabs=javascript

I use Postman to test the request outcome. Please note that I am a novice/beginner at generating API calls for Office Graph.
Somehow, the request is being answered with an 500 error:

{
"error": {
"code": "InternalServerError",
"message": "Unexpected end when reading token. Path 'assignments.c52fede4-537a-4fac-b2b9-033224cc5753'.",
"innerError": {
"request-id": "5cb01562-5b48-4b1d-81f2-2652973b1709",
"date": "2019-05-15T21:41:28"
}
}
}

My API call is quite the same as how Microsoft described it in its article, as follows:

POST https://graph.microsoft.com/v1.0/planner/tasks

Headers used:
Key: Content-Length
Value: 285
Key: Authorization
Value: Bearer eyJ……….
Key: Content-Type
Value: application/json

Body used

{
"planId": "rdKJDnc............",
"bucketId": "EOBeGf................",
"title": "Just some title",
"assignments":{
"c52fede4-537a-....................Azure AD User Object ID": {
"@odata.type": "#microsoft.graph.plannerAssignment",
"orderHint": " !"
}
}
}

In Microsoft's example, they include a comma before the last curly bracket. Postman is giving me an error when I leave this comma as it is.

I am struggling for the whole evening to find a clue to this issue. Is the example provided by Microsoft not complete? I assume that it is ready to use, and that I only need to change the variables.

I hope the description of my issue is clear enough.

Thanks in advance for your help!

Joost

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

picture joostvdlinden

All 4 comments

Yes the comma is erroneous. The error looks like a json parsing issue. I’ve noticed that you have the exact same content-length in your request from the sample. Is that number actually correct for your request? That may be the issue, as the error seems to be indicative of the content being terminated abruptly.

From: joostvdlinden notifications@github.com
Sent: Wednesday, May 15, 2019 2:55 PM
To: microsoftgraph/microsoft-graph-docs microsoft-graph-docs@noreply.github.com
Cc: Tarkan Sevilmis tarkanse@microsoft.com; Mention mention@noreply.github.com
Subject: [microsoftgraph/microsoft-graph-docs] New Planner Task error - InternalServerError - Unexpected end when reading token (#4609)

Dear all,

I am trying to create a new task in Microsoft Planner through the use of the Office Graph API.
I use this article as a reference: https://docs.microsoft.com/en-us/graph/api/planner-post-tasks?view=graph-rest-1.0&tabs=javascripthttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fgraph%2Fapi%2Fplanner-post-tasks%3Fview%3Dgraph-rest-1.0%26tabs%3Djavascript&data=02%7C01%7Ctarkanse%40microsoft.com%7C0ec1821e7c5448fa8df408d6d980061a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935541243405734&sdata=9jXTPpc%2FRXgWwkWueDIEsA6P4xkQFkc9%2B%2FgWCFZOTX4%3D&reserved=0

I use Postman to test the request outcome. Please note that I am a novice/beginner at generating API calls for Office Graph.
Somehow, the request is being answered with an 500 error:

{
"error": {
"code": "InternalServerError",
"message": "Unexpected end when reading token. Path 'assignments.c52fede4-537a-4fac-b2b9-033224cc5753'.",
"innerError": {
"request-id": "5cb01562-5b48-4b1d-81f2-2652973b1709",
"date": "2019-05-15T21:41:28"
}
}
}

My API call is quite the same as how Microsoft described it in its article, as follows:

POST https://graph.microsoft.com/v1.0/planner/taskshttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgraph.microsoft.com%2Fv1.0%2Fplanner%2Ftasks&data=02%7C01%7Ctarkanse%40microsoft.com%7C0ec1821e7c5448fa8df408d6d980061a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935541243415742&sdata=mFGsGeFwX6ERt9RLA8n8wW2uSW0FEw7x0c4u3PqBaOM%3D&reserved=0

Headers used:
Key: Content-Length
Value: 285
Key: Authorization
Value: Bearer eyJ……….
Key: Content-Type
Value: application/json

Body used

{
"planId": "rdKJDnc............",
"bucketId": "EOBeGf................",
"title": "Just some title",
"assignments":{
"c52fede4-537a-....................Azure AD User Object ID": {
"@odata.type": "#microsoft.graph.plannerAssignment",
"orderHint": " !"
}
}
}

In Microsoft's example, they include a comma before the last curly bracket. Postman is giving me an error when I leave this comma as it is.

I am struggling for the whole evening to find a clue to this issue. Is the example provided by Microsoft not complete? I assume that it is ready to use, and that I only need to change the variables.

I hope the description of my issue is clear enough.

Thanks in advance for your help!

Joost

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoftgraph%2Fmicrosoft-graph-docs%2Fissues%2F4609%3Femail_source%3Dnotifications%26email_token%3DADY26S654D25CCBA6XVOR6LPVSBEPA5CNFSM4HNHJGY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUBAQRA&data=02%7C01%7Ctarkanse%40microsoft.com%7C0ec1821e7c5448fa8df408d6d980061a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935541243435755&sdata=cSXFSSB1FUht2P0EY0tDA1XNFu22L%2FPJKVh5CIa3Q%2B4%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADY26S2QI44NICL4N7VOPU3PVSBEPANCNFSM4HNHJGYQ&data=02%7C01%7Ctarkanse%40microsoft.com%7C0ec1821e7c5448fa8df408d6d980061a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935541243445763&sdata=541UCNmbDVJ3S4ucQhZxXNoOidVUkvEwANZ%2BnGkHbu0%3D&reserved=0.

TarkanSevilmis picture TarkanSevilmis on 16 May 2019
🎉1

Yes the comma is erroneous. The error looks like a json parsing issue. I’ve noticed that you have the exact same content-length in your request from the sample. Is that number actually correct for your request? That may be the issue, as the error seems to be indicative of the content being terminated abruptly.

Dear @TarkanSevilmis,
Thank you for your help. I really appreciate it.

I have increased the Content-Length value. My findings are interesting (_I still use Postman to troubleshoot_):

When I use Content-Length value <= 300, I get response:

{
"error": {
"code": "InternalServerError",
"message": "Unexpected end when reading token. Path 'assignments.c52fede4-537a-4fac-b2b9-033224cc5753'.",
"innerError": {
"request-id": "99955ac0-e051-4c12-b8f9-4241990177ff",
"date": "2019-05-16T06:31:15"
}
}
}

When I use Content-Length value = 301, 302 or 303, I get response:

{
"error": {
"code": "BadRequest",
"message": "Unable to read JSON request payload. Please ensure Content-Type header is set and payload is of valid JSON format.",
"innerError": {
"request-id": "4feec4bf-c62d-4802-bca7-dbdb2020b62f",
"date": "2019-05-16T06:33:51"
}
}
}

When I use Content-Length value >= 304 and <= 318, I get response:

{
"error": {
"code": "InternalServerError",
"message": "Unexpected end when deserializing object. Path 'assignments.c52fede4-537a-4fac-b2b9-033224cc5753.orderHint', line 8, position 23.",
"innerError": {
"request-id": "67557b06-a166-422e-9753-001166dec61c",
"date": "2019-05-16T06:37:05"
}
}
}

When I use Content-Length value = 319, it works!! Why does it matter that much, the exact value of Content-Length? I have also noticed that when I completely remove the Content-Length property from the request's headers, it also works!

I thought it was a required property since it was included in Microsoft's example.

joostvdlinden picture joostvdlinden on 16 May 2019
🎉1

Content-Length is pretty much required in the HTTP protocol, which is the basis of most modern web requests. It identifies the length of the request content. You can read more about the header here: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Since it is essential, I’d think Postman (or most web request libraries) would add this automatically for you (based on the content of the request), without you needing to explicitly specify it yourself.

From: joostvdlinden notifications@github.com
Sent: Wednesday, May 15, 2019 11:48 PM
To: microsoftgraph/microsoft-graph-docs microsoft-graph-docs@noreply.github.com
Cc: Tarkan Sevilmis tarkanse@microsoft.com; Mention mention@noreply.github.com
Subject: Re: [microsoftgraph/microsoft-graph-docs] New Planner Task error - InternalServerError - Unexpected end when reading token (#4609)

Yes the comma is erroneous. The error looks like a json parsing issue. I’ve noticed that you have the exact same content-length in your request from the sample. Is that number actually correct for your request? That may be the issue, as the error seems to be indicative of the content being terminated abruptly.

Dear @TarkanSevilmishttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FTarkanSevilmis&data=02%7C01%7Ctarkanse%40microsoft.com%7Cb87e3a3b927b46e02a6f08d6d9ca7733%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935860938853938&sdata=DvR8WL8HRYSe3lwFnNGIBmIib3%2BQ8WnQjPpJKKLdemo%3D&reserved=0,
Thank you for your help. I really appreciate it.

I have increased the Content-Length value. My findings are interesting (I still use Postman to troubleshoot):

When I use Content-Length value <= 300, I get response:

{
"error": {
"code": "InternalServerError",
"message": "Unexpected end when reading token. Path 'assignments.c52fede4-537a-4fac-b2b9-033224cc5753'.",
"innerError": {
"request-id": "99955ac0-e051-4c12-b8f9-4241990177ff",
"date": "2019-05-16T06:31:15"
}
}
}

When I use Content-Length value = 301, 302 or 303, I get response:

{
"error": {
"code": "BadRequest",
"message": "Unable to read JSON request payload. Please ensure Content-Type header is set and payload is of valid JSON format.",
"innerError": {
"request-id": "4feec4bf-c62d-4802-bca7-dbdb2020b62f",
"date": "2019-05-16T06:33:51"
}
}
}

When I use Content-Length value >= 304 and <= 318, I get response:

{
"error": {
"code": "InternalServerError",
"message": "Unexpected end when deserializing object. Path 'assignments.c52fede4-537a-4fac-b2b9-033224cc5753.orderHint', line 8, position 23.",
"innerError": {
"request-id": "67557b06-a166-422e-9753-001166dec61c",
"date": "2019-05-16T06:37:05"
}
}
}

When I use Content-Length value = 319, it works!! Why does it matter that much, the exact value of Content-Length? I have also noticed that when I completely remove the Content-Length property from the request's headers, it also works!

I thought it was a required property since it was included in Microsoft's example.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoftgraph%2Fmicrosoft-graph-docs%2Fissues%2F4609%3Femail_source%3Dnotifications%26email_token%3DADY26S7AOFCL7YJ6XWISTFDPVT7SZA5CNFSM4HNHJGY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVQ22FY%23issuecomment-492940567&data=02%7C01%7Ctarkanse%40microsoft.com%7Cb87e3a3b927b46e02a6f08d6d9ca7733%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935860938863931&sdata=b3PdHuFR7BBQBD%2B0KTvto%2BZiyocsqpUqh96Z%2BsRrTRY%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADY26S3CKWCXCGFLBGPTKZTPVT7SZANCNFSM4HNHJGYQ&data=02%7C01%7Ctarkanse%40microsoft.com%7Cb87e3a3b927b46e02a6f08d6d9ca7733%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636935860938863931&sdata=NwQDL9qcQ5rPwsfyR6ANn91187OISJjXOFLwQSLEBVY%3D&reserved=0.

TarkanSevilmis picture TarkanSevilmis on 16 May 2019
👍1

You were completely right. After removing the Content-Length key, Postman added it automatically while sending the request.

Thank you for all your effort! And thanks for referring to more info. Case solved :-)

joostvdlinden picture joostvdlinden on 16 May 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

abhatt29 picture abhatt29  Â·  4Comments
climam picture climam  Â·  4Comments
RobinBreman picture RobinBreman  Â·  4Comments
aaronrogers picture aaronrogers  Â·  3Comments
dagexiongfeng picture dagexiongfeng  Â·  4Comments