Could not load session:404: Not Found error

[ray-cuadra]

It looks like the issue with the old Estimate board has not been resolved. Would you be able to help with this issue? Background the Project Collection was created before TFS 2019 Server, I recently upgraded the server instance to ADO Server 2020.

{"$id":"1","innerException":null,"message":"%error="1660002";%:The collection does not exist\r\n%error="1660002";%:The collection does not exist","typeName":"Microsoft.VisualStudio.Services.ExtensionManagement.WebApi.DocumentCollectionDoesNotExistException, Microsoft.VisualStudio.Services.ExtensionManagement.WebApi","typeKey":"DocumentCollectionDoesNotExistException","errorCode":0,"eventId":3000}

BTW, we are using HTTPS

[hangy]

It looks like the issue with the old Estimate board has not been resolved. Would you be able to help with this issue? Background the Project Collection was created before TFS 2019 Server, I recently upgraded the server instance to ADO Server 2020.

This is similar to our setup, which is an old TFS 2010 upgraded through Azure DevOps Server 2020.0.1. Are you getting the 404 when listing, creating or joining a session? Could try setting up the work item fields with the gear icon to see if that changes the error?

[ray-cuadra]

Does it need to all be filled? Also, I assume it can be any field. I also attach a screenshot so you will see some of the field names are not showing up as easy to read. Minor thing. BTW the issue is when you try to open it that when I get the 404. The odd thing is the other projects collection works fine so trying to understand what is causing the issue with this project.

[hangy]

Are you sure it's a different project collection, not a project created before v2019? microsoft/featuretimeline#214 sounds similar, and cschleiden#86 (comment) is probably the same upstream.

Does it need to all be filled? Also, I assume it can be any field.

Reading the aforementioned issues, it doesn't seem to be related to that after all. Just the fields/types that are actually in use need to be defined.

[ray-cuadra]

The project was created before V2019 but I have other projects that was created before as far back as 2016 and even later that as well and those seems to work. So I'm at a lost as to what is different with this project to not work.

The link that you mentioned is not the same for my case, I included a screenshot as to where it is happening. Steps to recreate:

1. select 2 User Stories and select Estimates.
2. enter a name and the type of card to use the click create,

It will create it but when you click the name it gives you a 404 error.

[ray-cuadra]

tried creating the estimate using queries, same result will create but when you click it errors out.

[ray-cuadra]

Hi Hangy, I might have found something for you to try to recreate. It seems like any of my project that has "Agile" as the process template is getting the 404 error.

The one project that is working fine for some odd reason does not have a Process template listed. While the non working project has Agile. But both are using Agile templates.

[hangy]

Thanks for the repro idea, @ray-cuadra! As you've found out, the error loooks to be related to the process type. Apparently, for a project with this new "inheritance" model, the extension requests the workitems from two URLs:

1. https://tfs.example.org/SomeProjectCollection/{SomeGuid}/_apis/wit/workItemTypes
2. https://tfs.example.org/SomeProjectCollection/_apis/work/processes/adcc42ab-9882-485e-a3ed-7678f01f66bc/workItemTypes

The latter call is not present in older (XML?) based process configurations, and 404s in our "agile" project, probably causing the 404 error.

[ray-cuadra]

Will you be able to fix the issue?

[hangy]

Will you be able to fix the issue?

I'm looking into it. At the very least, it should be possible to ignore the 404, but this extension then probably would not work with derived process versions. I'll see what I can do and what might be incorrect upsteam/in AzDO Server, since the REST endpoint actually somewhat exists in the docs.

[ray-cuadra]

I appreciate all the help hangy. Thank you!

[hangy]

I opened a new item on the MS Developer Community (https://developercommunity.visualstudio.com/t/Work-Item-Types---List-404/1424164?space=22) to see what the Microsoft engineering teams know about this. Feel free to add anything I may have missed. 🙂

[ray-cuadra]

Thank you hangy since I'm not a developer I do not have enough insight as to what else is needed :-) , it just so happen that when I look at the project I saw the difference between the non-working project and the working project. The odd thing here is that 95% of our project are using Agile template so not sure why some will have it set and other are not.

BTW, one thing change recently is that in ADO Server 2019 the URL has "tfs" in it (i.e. https://someorg.com/tfs/defaultcollection) since in IIS it has an application directory called "tfs" with the most recent upgrade to ADO Server 2020, Microsoft seemed to phase out any reference to "tfs" and they decided to remove the application directory completely and now the URL is https://someorg.com/defaultcollection.

When I upgrade I usually upgrade my servers as well so it is easy to go back if and when something happens during the upgrade process that is the reason why the virtual directory will never be retained in my environment.

[hangy]

@ray-cuadra After some back and forth (which I had to mark as private because of internal URLs), MS is now looking into why the subresource doesn't work. I'm holding off of just swallowing the error a bit longer, until we hopefully get a response from MS.

[ray-cuadra]

No problem thank you Hangy for the update.

[hangy]

FWIW, updating to AzDO 2020.1 didn't change this situation.

[ray-cuadra]

Hi Hangy, have you heard anything as to when this can be resolved?

[hangy]

Hi @ray-cuadra, up until a few days ago, I had hoped that MS might do something about it, but MS has recently closed my question as not a bug. Since I'm pretty sure it's caused by an API issue and not this extension, I asked them to reconsider.

If there's no response soon, I'll see how/if it still works, if we skip the failing call.

[hangy]

Microsoft has recently moved the development of the original extension here, so there might be a chance to get this fixed if it happens with that version, too.

[ray-cuadra]

That is good news Hangy I'm not holding my breath , but I'm optimistic.