Search Issue Tracker
Won't Fix
Won't Fix in 2020.3.X, 2021.3.X, 2022.1.X, 2022.2.X, 2023.1.X
Votes
0
Found in
2020.3.42f1
2021.3.14f1
2022.1.23f1
2022.2.0b15
2023.1.0a19
Issue ID
UUM-19284
Regression
No
Package Refresh hangs when used Packages are from a repository that uses Global Protect VPN without being connected
How to reproduce:
1. Turn on the “Global Protect” VPN
2. Open the user-attached project
Expected result: The project opens without issues
Actual result: The project takes too long to open
Reproducible with: 2020.3.42f1, 2021.3.14f1, 2022.1.23f1, 2022.2.0b15, 2023.1.0a19
Reproduced on: macOS Monterey 12.6 (Intel)
Note: Waited up to an hour, then stopped the process through Task Manager
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Graphics Settings: “Use Defaults” checkboxes misaligned in Tier Settings section
- VFX Graph particles are not culled when using URP and Frustum Culling is enabled on VFX Mesh Output
- Texture2D hash changes inside of an AssetBundle when rebuilding a SpriteAtlas bundle with an empty AssetPostprocessor Script enabled
- Aniso Level still applies when Generate MipMap is disabled in Texture Import Settings
- Mipmap Limit Groups long names are not truncated when creating a new Mipmap Limit Group with a long name
Resolution Note:
There are no fixes planned for this Bug
Resolution Note (2023.1.X):
There are no fixes planned for this Bug
Resolution Note (2023.1.X):
This report highlights the usability issues in the case of a service being unreachable that does not fail with an error immediately but instead times out eventually (depending on the default OS timeout). This situation can lead to essentially locking up the Editor as soon as there is a non-trivial number of packages in the project.
Some VPN-protected servers would treat requests from clients not connected to the VPN if it didn't exist, simply not responding to the connection request. Other VPN configurations might instead immediately refuse the connection or respond with an HTTP error response (such as 403), resulting in immediate failure instead of potentially very long timeouts. We understand that saying this doesn't help, but we thought it might help provide a bit more context on the issue.
Unfortunately, there is no single way for us to fix this problem. We do have several ideas on how to improve this so that in the given situation, such as implementing faster connection timeouts or specifically detecting timeouts and eagerly skipping subsequent requests to the same server, such that the Package Manager does not end up blocking the Editor for so long. We plan on implementing some of these improvements gradually, but we are not being able to provide any ETA on these improvements, for which we apologize.
Resolution Note (2022.2.X):
This report highlights the usability issues in the case of a service being unreachable that does not fail with an error immediately but instead times out eventually (depending on the default OS timeout). This situation can lead to essentially locking up the Editor as soon as there is a non-trivial number of packages in the project.
Some VPN-protected servers would treat requests from clients not connected to the VPN if it didn't exist, simply not responding to the connection request. Other VPN configurations might instead immediately refuse the connection or respond with an HTTP error response (such as 403), resulting in immediate failure instead of potentially very long timeouts. We understand that saying this doesn't help, but we thought it might help provide a bit more context on the issue.
Unfortunately, there is no single way for us to fix this problem. We do have several ideas on how to improve this so that in the given situation, such as implementing faster connection timeouts or specifically detecting timeouts and eagerly skipping subsequent requests to the same server, such that the Package Manager does not end up blocking the Editor for so long. We plan on implementing some of these improvements gradually, but we are not being able to provide any ETA on these improvements, for which we apologize.
Resolution Note (2022.1.X):
This report highlights the usability issues in the case of a service being unreachable that does not fail with an error immediately but instead times out eventually (depending on the default OS timeout). This situation can lead to essentially locking up the Editor as soon as there is a non-trivial number of packages in the project.
Some VPN-protected servers would treat requests from clients not connected to the VPN if it didn't exist, simply not responding to the connection request. Other VPN configurations might instead immediately refuse the connection or respond with an HTTP error response (such as 403), resulting in immediate failure instead of potentially very long timeouts. We understand that saying this doesn't help, but we thought it might help provide a bit more context on the issue.
Unfortunately, there is no single way for us to fix this problem. We do have several ideas on how to improve this so that in the given situation, such as implementing faster connection timeouts or specifically detecting timeouts and eagerly skipping subsequent requests to the same server, such that the Package Manager does not end up blocking the Editor for so long. We plan on implementing some of these improvements gradually, but we are not being able to provide any ETA on these improvements, for which we apologize.
Resolution Note (2021.3.X):
This report highlights the usability issues in the case of a service being unreachable that does not fail with an error immediately but instead times out eventually (depending on the default OS timeout). This situation can lead to essentially locking up the Editor as soon as there is a non-trivial number of packages in the project.
Some VPN-protected servers would treat requests from clients not connected to the VPN if it didn't exist, simply not responding to the connection request. Other VPN configurations might instead immediately refuse the connection or respond with an HTTP error response (such as 403), resulting in immediate failure instead of potentially very long timeouts. We understand that saying this doesn't help, but we thought it might help provide a bit more context on the issue.
Unfortunately, there is no single way for us to fix this problem. We do have several ideas on how to improve this so that in the given situation, such as implementing faster connection timeouts or specifically detecting timeouts and eagerly skipping subsequent requests to the same server, such that the Package Manager does not end up blocking the Editor for so long. We plan on implementing some of these improvements gradually, but we are not being able to provide any ETA on these improvements, for which we apologize.
Resolution Note (2020.3.X):
This report highlights the usability issues in the case of a service being unreachable that does not fail with an error immediately but instead times out eventually (depending on the default OS timeout). This situation can lead to essentially locking up the Editor as soon as there is a non-trivial number of packages in the project.
Some VPN-protected servers would treat requests from clients not connected to the VPN if it didn't exist, simply not responding to the connection request. Other VPN configurations might instead immediately refuse the connection or respond with an HTTP error response (such as 403), resulting in immediate failure instead of potentially very long timeouts. We understand that saying this doesn't help, but we thought it might help provide a bit more context on the issue.
Unfortunately, there is no single way for us to fix this problem. We do have several ideas on how to improve this so that in the given situation, such as implementing faster connection timeouts or specifically detecting timeouts and eagerly skipping subsequent requests to the same server, such that the Package Manager does not end up blocking the Editor for so long. We plan on implementing some of these improvements gradually, but we are not being able to provide any ETA on these improvements, for which we apologize.