Cli-microsoft365: Bug UnhandledPromiseRejectionWarning - 404 when creating a team using teams team add
Description
When executing the m365 teams team add --name 'Architecutre' --description 'Architecture' command you might receive 404 error message like this one:
UnhandledPromiseRejectionWarning: StatusCodeError: 404 - {"error":{"code":"NotFound","message":"No team found with Group Id 58c19f12-6bb5-4846-8ccd-36d9eb04ef2a","i
nnerError":{"date":"2020-10-25T08:59:38","request-id":"083e431a-deb6-4f85-987e-a59487c18cea","client-request-id":"083e431a-deb6-4f85-987e-a59487c18cea"}}}
The Team is being created but the operation to retrieve group information fails because graph still does not have the group available when querying it.
The suggestion is to put a try catch with retries (for example up to 5 with a sleep time of 5 seconds) until the result is correctly returned.
Steps to reproduce
- execute the command m365 teams team add --name 'Architecutre' --description 'Architecture'
- It will throw an exception
- The team is created but the command fails due to the lines trying to return the group object
Expected result
- Command does not return an exception
Environment
- Windows 10
- PowerShell
- Latest Microsoft 365 CLI
plamber
All 24 comments
I believe I've heard something about a new API that should allow for synchronous Teams creation. Let's check if we're using that API already and if not, see if we could switch to it for more reliable teams creation.
waldekmastykarz
on 25 Oct 2020
You are correct @waldekmastykarz, the beta endpoint returns a team creation object and a reference to another endpoint so you can check the status of your request.
The current v1.0 endpoint returns a 404 if the underlying group is not provisioned immediately as @plamber points out.
I believe the guidance from the Graph team is that this can take up to 15 mins for the Group to be provisioned however.
garrytrinder
on 25 Oct 2020
Let me check if I can dig up any more information on it
waldekmastykarz
on 26 Oct 2020
Looks like the beta endpoint just went GA.
garrytrinder
on 26 Oct 2020
@garrytrinder: from experience it is not taking so long provisioning a group. Usually, the group should be there asap. Looking it up a couple of seconds later if it hasn't been found before should suffice.
plamber
on 26 Oct 2020
Apologies @plamber looks like I didn't quite understand the issue you reported here.
You are referring to the request made below to the group endpoint after the teamsAsyncOperation status has returned as Succeeded.
As we are currently using the beta/teams endpoint for creating the Team, I think we should look to update this command to use the v1.0 endpoint now it is in GA, maybe that will provide more reliability, if not we can look to add some defensive code to cover a potential timing issue in the Graph.
garrytrinder
on 26 Oct 2020
@garrytrinder: step 1 is definitively the update. The v1.0 endpoints are much faster. Nevertheless, we need a fallback on that specific command because from experience these operations are not synchronous in nature
Something similar happens if you create a group and you try to immediately create a team afterwards. In many cases it works immediately but in some you have to perform some retries up to 15 seconds in average.
plamber
on 27 Oct 2020
Just to verify the proper way forward: what's the best way to handle the error in a consistent way? Imagine you build a script and expect to use the response we typically return in the following actions. If we hide the error, it would mean that we sometimes return something and other times nothing, which is very unpredictable. If we can't rely on the API always returning a value, we should consider not returning anything and instructing users to always retrieve the information about the newly created Team separately.
waldekmastykarz
on 28 Oct 2020
@waldekmastykarz
The only consistent thing that we can ensure is returning immediately the team ID without performing additional queries for the MS Group. Everything else requires us to create some fallback approaches. If we do not do this, then the person writing the script has to handle these exceptions.
plamber
on 28 Oct 2020
If we can reliably return team ID, then let's do that.
waldekmastykarz
on 28 Oct 2020
Apologies @plamber looks like I didn't quite understand the issue you reported here.
You are referring to the request made below to the
groupendpoint after theteamsAsyncOperationstatus has returned asSucceeded.As we are currently using the
beta/teamsendpoint for creating the Team, I think we should look to update this command to use the v1.0 endpoint now it is in GA, maybe that will provide more reliability, if not we can look to add some defensive code to cover a potential timing issue in the Graph.
@garrytrinder we are using 1.0 for team creation, couple of months ago we used beta as 1.0 was not available. Works better than beta, especially when after creation we want to add tabs/apps or call sitedesign for sharepoint. In many cases we get 404 error.
ValerasNarbutas
on 28 Oct 2020
Let me check if I can dig up any more information on it
@waldekmastykarz, @garrytrinder I found this working better:
- create/clone team. It does return location in header
- call graph with https://graph.microsoft.com/v1.0/{Location} which returns operation status. When doing it in the loop in flow very quickly I can see return status of creation operation changing from in Progress to succeed. An only when I get "Succeed" i am doing something with team.
nice thing that when checking via https://graph.microsoft.com/v1.0/{Location} you also getting team id, can be found either in {Location} value or use response ResourceId which is also team id.
@waldekmastykarz would be nice to have some insight from MS about endpoints and async creation mainly on how or most importantly when sharepoint sites are created. I have a number of examples of sites not get created sometimes unless "files" tab clicked in teams.
So I assume clicking it does call some endpoint. would be great to know which one and if I can use it for provisioning solutions.
ValerasNarbutas
on 28 Oct 2020
@ValerasNarbutas the problem lies here:
When the status !== succeeded the code is immediately calling the groups endpoint to return the group. This is a too optimistic approach considering that all these operations are asynchronous. The moment the code is calling the group endpoint might be still to early (even if you already got the teamid - which is the group id in the backend). In some situations you have to wait a little until the group can be retrieved using the graph endpoint. It is analog if you do it in the inverse order. When you create a group you can't immediately call the teams endpoint because there might be some timing issues.
From the suggested solutions you have two approaches:
- You create a fallback for the get group operation and you rerun it a couple of times with a sleep between
- You are just returning the teamid from the location header
You are not experiencing this issue with the "synchronous" operation because there was plenty of time to provision the Group while you are waiting that the template is applied correctly.
plamber
on 29 Oct 2020
@waldekmastykarz would be nice to have some insight from MS about endpoints and async creation mainly on how or most importantly when sharepoint sites are created. I have a number of examples of sites not get created sometimes unless "files" tab clicked in teams.
I know for one that it's a complex process involving multiple services. Let me see if I can find out more and get back to you.
waldekmastykarz
on 29 Oct 2020
@ValerasNarbutas what I've been able to learn so far is that the recommendation is to use the v1.0 API. I don't have any additional information right now, but if there are any specific scenarios for which you'd need to know when the SharePoint site is ready, I'd be glad to pass them on to the Product Group.
waldekmastykarz
on 30 Oct 2020
Hey @plamber, @ValerasNarbutas, @garrytrinder, do we have a consensus as to how to proceed to address this issue?
waldekmastykarz
on 12 Nov 2020
Hi,
not sure if we have a consensus yet. Its just about to decide if we want to have a fallback loop there or if we do not want to return the MS Group object at all.
I would even consider not returning the Group at all and let the person writing the script doing that for performance reasons. On the other hand, we tend to provide scripts that provide more convenience, therefore, the fallback solution might be more our CLI style.
Just let me know what you guys prefer.
br,
Patrick
plamber
on 13 Nov 2020
For backwards compatibility, I'd say let's keep the current behavior. If need be, we can revisit it for the next major version.
waldekmastykarz
on 13 Nov 2020
@waldekmastykarz i do agree, for this specific behavior i do use @plamber suggestion with loop, to be fare not used in the script but rather MS automate with loop + calls to graph API until I get operation status success :) but its basically does the same thing
ValerasNarbutas
on 18 Nov 2020
All right, so the consensus is to add a loop that will keep waiting until the group has been created, correct?
waldekmastykarz
on 18 Nov 2020
@ValerasNarbutas: is this something you would like to pick-up?
Thank you for your feedback
plamber
on 20 Nov 2020
@waldekmastykarz @plamber
As there are two changes to be made here, I think we should we create two new issues to carry out the work.
One to update to the v1.0 endpoint and another to include the loop as an enhancement as we have discussed here, this makes our intentions clearer.
Do you agree?
garrytrinder
on 22 Dec 2020
Good idea. Let's do it.
waldekmastykarz
on 22 Dec 2020
Issues #2020 & #2021 raised as discussed.
Thank you for your input all, lets move this forward 馃憤
garrytrinder
on 22 Dec 2020
Related issues
plamber
路
3Comments
VelinGeorgiev
路
3Comments
plamber
路
3Comments
arjunumenon
路
3Comments
thomyg
路
3Comments
Most helpful comment
All right, so the consensus is to add a loop that will keep waiting until the group has been created, correct?