Mismatched Host header using proxy in XplatGenerateReleaseNotes@3.39.2
LouisSung opened this issue · 7 comments
Describe the bug
As of XplatGenerateReleaseNotes@3.39.2, the "azure-devops-node-api": "^8.1.1" is used.
However, some issues are fixed between the latest azure-devops-node-api@10.2.0 and azure-devops-node-api@8.1.1, such as microsoft/typed-rest-client#163
To Reproduce
All API calls are effected by this bug
Expected behavior
Should update the dependency as the latest version, at least 10.1.0
Related issues
- I soon raised a PR nodejs/node#36805 to fix the Host header mismatch issue at the Node.js runtime level (root cause)
- However, by communicating with Microsoft support team today, this issue has been addressed in microsoft/typed-rest-client#163 and koichik/node-tunnel#29 that fixed by microsoft/typed-rest-client#195 and deployed since node-tunnel@0.0.6, microsoft/typed-rest-client@1.7.2 and microsoft/azure-devops-node-api@10.1.0.
I will get sorted ASAP
It has been shipped in 3.40.10
I'll check it with packet analyzer tomorrow
Thank you~
Sorry about causing the #928 _(;3
We also met the error when I check yesterday, but I'm blocked from our company's firewall and cannot reply or comment...
I have to clone the source code, revert, build, and push our own version to market and then replace the task for all the taskgroups we have; otherwise, it impacts hundreds of our release pipelines
Is there any good mechanisms to keep the stable version or delay the deployment?
Since users cannot force specify or downgrade the minor version in Azure DevOps...
#928 was going to happen in the end when I got around to a library upgrade, hopefully 3.41.x fixes it as it is a known issue. It is a bit concerning that all my test pass 100% and my own companies usage is fine with both 3.40.x and 3.41.x, I am obviously missing some edge case, just not sure what it is yet.
I seems #928 is now addressed, but of not I will probably be rolling back the library in the 3.x branch and make the change on 4.x to allow people to swap when they choose
Oh, I miss the reply again...
The #929 shipped as 3.41.31 also fixes our problems, so I think it's safe to close #928.
I think what I learned from this issue is that CI may covers most of the logic parts but maybe not the configurations or environment parts.
For example, the CI pipeline run using Microsoft's public agent; therefore, the issue #928 was not detected due to it's specific to on-premises agents.
(also issues like empty work items, the default configuration changes but the CI environment doesn't reflect that situation)
I know it's not anyone's fault and you also response to issues very very fast, but Azure provides no ways to revert version manually (I've even tried to use API to change version from 3.* to 3.40.10 but it turns out invalid versioning error message).
Not to say that providing stable or deferred updated version is essential but it worth considering if the change may impact a lot :)
But still, I don't feel providing another versions like
4.*would be a good practice in the semantic versioning point of view...
We have to self-host our own version afterward to keep things stable because we apply this task to all of our release pipelines and therefore couldn't afford any failures _(;3
Incrementing the major version cause problems of it's own, basically most people don't upgrade and support become harder due to parallel versions. Hence, I only 'up' the major number when there is major breaking change or more commonly major rewrite, and the minor number for all other non breaking changes/bug fixes. Noting that I always add defaults to keep functionality the same for existing users where possible,
This issue should not have been a breaking change. However, it has shown I do need to alter my release process, especially if there a library updates, to do extra testing on premise agents and even Azure DevOps Server.