Hi, I just updated Unity to v2019.3.0f6 and the packages from my company’s private registry are not displayed in UPM UI anymore.
We are using Verdaccio
it is working correctly on Unity 2019.2
on our local registry I can see a 404 error for the route “/-/v1/search” when Unity updates the UPM package list
I know that Unity had support for “/all” only in versions previous to 2019.3. It seems that 2019.3 implements the new npm search route. Is the “/all” route support discontinued for the new Unity version ?
You are right, the Package Manager now first try to fetch packages through the “/-/v1/search”. But, if it fails, we resort to the “/-/all” route to fetch all packages. You don’t see a “/all” request just after the 404?
Thank you for your fast answer. I just checked and you are right. I compared the requests made by Unity 2019.2 and Unity 2019.3.
2019.3 : The “/-/v1/search” fails. It falls back on “/-/all”. The server replies with the list of packages and a 200 status code as intended. However the packages aren’t displayed in Unity and the Unity’s npm cache stays empty.
2019.2 : The request to “/-/all” works the same way but then Unity seems to make requests individually to every package that matches the scope. The npm cache is filled and the packages are shown in UPM.
Do you have any news ? We are studying the possibility to upgrade our production pipeline to Unity 2019.3 at my company and this issue is quite blocking for us.
Sorry. I missed your post. This may be a bug. Would you mind providing a project manifest exposing the bug? If you could create a bug report we the required information it would be awesome.
We’re seeing the same, this is a regression in 2019.3. After adding a scoped registry Unity needs at least one, sometimes multiple, restarts until the packages are shown. Sometimes they’re only shown after manually adding one of the packages in that registry to the manifest.
This is a regression to 2019.3.0f3 or even 0f5 - again a workflow regression introduced in a release version…
Hi Pascal, thank you for you answer. Unfortunately the manifest I use won’t be of any help to reproduce the bug as my company’s Verdaccio server can only be accessed from a local network for privacy purposes. Although I made a test with OpenUPM packages added as scopedRegistries that has this bug too, I will make a bug report with it.
I encounter the same bug, for what its worth. 2019.3.0f6, I can see the /all endpoint is succesfully queried but packages don’t show in the UI (adding them manually works fine)
We’re experiencing the same bug as well. 2019.2 works, 2019.3.0f6 does not.
When accessing our registry server in 2019.3, the following error appears in %localappdata%\Unity\Editor\upm.log :
[2020-02-12T14:27:13.756Z][ERROR]
{
"message": "The url [http://192.168.0.8:4873/-/all] did not return a JSON response.",
"stack": "Error: The url [http://192.168.0.8:4873/-/all] did not return a JSON response.\n at Object.getJson (C:\\snapshot\\upm\\node_modules\\@upm\\core\\lib\\private\\utilities\\request.js:0:0)\n at <anonymous>\n at process._tickDomainCallback (internal/process/next_tick.js:228:7)"
}
We’re running Verdaccio 4.4.0, and the verdaccio log says:
Accessing http://192.168.0.8:4873/-/all directly via browser or curl DOES return a valid JSON file, containing all packages of the registry.
Further info: 2019.2 does generate the file %localappdata%\Unity\cache\npm\192.168.0.8_4873\192.168.0.8_4873-\all.cache.json , which IS the downloaded JSON file.
2019.3 does NOT generate this file,but it DOES evaluate it, if it was generated by 2019.2 (=> so this is a viable workaround to still be able to use scoped registries with 2019.3, except the necessity to have 2019.2 update this file each time the list of packages on the registry server changes…
Our QA was able to reproduce the issue. A developer is trying to find the cause at this moment. We should have a resolution to this problem soon. Really sorry about this!
Glad to see you found a temporary workaround. I’ll give you more details on the issue. Maybe it will help you figure out another workaround. The gist of the issue is that we added HTTP response validation that was a bit too strict. UPM would reject the response as not being valid JSON even if the body was (ex: Missing response content-type header or different than application/json). I believe Verdaccio doesn’t return the content-type in the response headers and makes UPM simply reject the request :(.
We were already aware of this issue (but with a different symptom) and made a fix that landed in 2020.1.0a17. If you have a chance to try with this release and see if the issue is still there for you, that would be really appreciated!
As @okcompute_unity says, we believe this was the Content-Typer header check we implemented. If you like, you could run curl -I http://192.168.0.8:4873/-/all and verify the Content-Type value or lack thereof. If it’s not application/json then we’ve found the culprit