The theory is a version with the same major but with the maximum lower minor will be the closest in behavior, then the maximum version that is lower than the current version is most likely to have the same behavior. If there is no smaller known version, it will just use the minimum version that is higher.
This logic may not always work. But with the given circumstances, we are covered by including the first version where preinstall commands were not needed
Axios already has its own timeout, so we dont need a 2nd timeout handler, I was able to confirm it works by using https://httpstat.us/524, and it does report the time it took to timeout in a similar fashion. We will get more information from errors this way when it is available.
This means the cache will not persist over different vscode windows, which is not optimal. However, until vs code does not fail with circular json references or non json objects with this cache, we do not seem to have ways to filter what goes into the cache and what does not. Even for one request, the no cache method still ends up putting things into the storage, see: https://axios-cache-interceptor.js.org/config/request-specifics#cache. Then, the request object given to set does allow us to filter some of the content per request, but even then, one request seems to cause multiple potential cache entries. In addition, I looked at the code of the axios-cache-interceptor- and the loading state never gets updated until something is in the cache, so my previous code was based on incorrect assumptions, even if the logic would have worked if we had that kind of graunlar control
https://axios-cache-interceptor.js.org/guide/storages The storage handler is supposed to prevent timed out requests from going into the cache per the documentation which it does not do.
Also, VS Code will try to unwrap a circular reference which the request will be circular in the TLS handshake. This is a 'bug' in serializeRequestArguments in extensionHostProcess.js from VS Code. This will prevent us from removing from the extension state in the future as trying to access it will cause an exception and cancel the request
This is in the dist folder, it should* be cleaned up worst case by upgrade/uninstall of the extension, we dont want to fail everything if we dont have perm to delete, this is a win arm64 problem for whichever reason
remove extra sdk feature band check thats already done in the linux distro code
make the context optional in places where it may not actually exist, e.g. if vs code telemetry setting is changed before we call an acquire command, there would be no acquire context
- First moving the mock object import in index.ts resolved the dependency loading order problem where classes were being imported out of order
- Then, removing the getInstallKey function out of the worker prevented loading the vscode module which will always cause a failure in the library tests
- Also cleans up imports and adds whitespace
Some problems remain post refactor which I will fix next
Do this to deduplicate event stream, timeout time, extension state, proxy url, arch, and install key so we can throw errors from other places
uses a hack for the telemetry observer because it needs to be created before the acquisition context can be created
Noah Gilson
Noah Gilson
JL03-Yue