Fix IIS recycle regressions#59998
Conversation
|
|
||
| // This queue does not have websockets enabled currently, adding the module will break all tests using this fixture. | ||
| if (!HelixHelper.GetTargetHelixQueue().ToLowerInvariant().Contains("windows.amd64.server2022")) | ||
| if (!(HelixHelper.GetTargetHelixQueue() ?? "").ToLowerInvariant().Contains("windows.amd64.server2022")) |
There was a problem hiding this comment.
Fix local websocket tests.
| <logFile logFormat="W3C" directory="%IIS_USER_HOME%\Logs" /> | ||
| <traceFailedRequestsLogging directory="%IIS_USER_HOME%\TraceLogFiles" enabled="true" maxLogFileSizeKB="1024" /> | ||
| <logFile logFormat="W3C" directory="%TEMP%\IISTests\Logs" /> | ||
| <traceFailedRequestsLogging directory="%TEMP%\IISTests\TraceLogFiles" enabled="true" maxLogFileSizeKB="1024" /> |
There was a problem hiding this comment.
Write logs to temp instead of user directory. If you know, you know.
There was a problem hiding this comment.
Copilot reviewed 5 out of 19 changed files in this pull request and generated no comments.
Files not reviewed (14)
- src/Servers/IIS/AspNetCoreModuleV2/AspNetCore/applicationmanager.cpp: Language not supported
- src/Servers/IIS/AspNetCoreModuleV2/AspNetCore/applicationmanager.h: Language not supported
- src/Servers/IIS/AspNetCoreModuleV2/AspNetCore/globalmodule.cpp: Language not supported
- src/Servers/IIS/IntegrationTesting.IIS/src/Http.SubApp.config: Language not supported
- src/Servers/IIS/IntegrationTesting.IIS/src/Http.config: Language not supported
- src/Servers/IIS/IIS/test/IISExpress.FunctionalTests/OutOfProcess/MultipleAppTests.cs: Evaluated as low risk
- src/Servers/IIS/IntegrationTesting.IIS/src/IISDeploymentParameterExtensions.cs: Evaluated as low risk
- src/Servers/IIS/IIS/test/Common.FunctionalTests/RequestResponseTests.cs: Evaluated as low risk
- src/Servers/IIS/IIS/test/Common.LongTests/StartupTests.cs: Evaluated as low risk
- src/Servers/IIS/IIS/test/Common.FunctionalTests/Infrastructure/EventLogHelpers.cs: Evaluated as low risk
- src/Servers/IIS/IIS/test/Common.FunctionalTests/Infrastructure/IISTestSiteFixture.cs: Evaluated as low risk
- src/Servers/IIS/IntegrationTesting.IIS/src/IISDeployerBase.cs: Evaluated as low risk
- src/Servers/IIS/IntegrationTesting.IIS/src/IISExpressDeployer.cs: Evaluated as low risk
- src/Servers/IIS/IIS/test/Common.FunctionalTests/MultiApplicationTests.cs: Evaluated as low risk
Comments suppressed due to low confidence (2)
src/Servers/IIS/IIS/test/Common.FunctionalTests/Infrastructure/Helpers.cs:259
- Ensure that the change to select the last site element is covered by tests.
.Elements("site").Last();
src/Servers/IIS/IntegrationTesting.IIS/src/IISDeployer.cs:34
- The variable
_siteIdis incremented without any checks or resets. This could potentially lead to an overflow if the application runs for a very long time and many sites are created. Consider adding a check to reset or handle the overflow scenario.
private int _siteId = 2;
| public static string OutOfProcessStarted(IISDeploymentResult deploymentResult) | ||
| { | ||
| return $"Application '/LM/W3SVC/1/ROOT' started process '\\d+' successfully and process '\\d+' is listening on port '\\d+'."; | ||
| return $"Application '/LM/W3SVC/\\d+/ROOT' started process '\\d+' successfully and process '\\d+' is listening on port '\\d+'."; |
There was a problem hiding this comment.
Why are we loosening from strictly matching on 1 to any digit here? I see there are other updates related to multi-site handling in this PR. Does that address the regression or is it a new feature?
There was a problem hiding this comment.
Multi-site handling was added to add test coverage for the regression. Technically we might be able to pass in the site id to these methods so it's not using regex.
|
Hello. I would like to know if there is an estimated date for this hotfix to be available so I can test it. I have 503 errors with MACHINE/WEBROOT and I believe this hotfix will resolve my issue. If I run this command: I get 503 errors on all websites on my server, and I have to recycle the application pool for all websites. This command started failing with .NET 9. Could this hotfix solve my problem? |
|
@captainsafia why is this still open? It is ridiculous that such a critical bug is open for a few months now. |
|
Is there any ETA for getting that merged? |
f7fbf14 to
4babaa5
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 20 out of 20 changed files in this pull request and generated 2 comments.
Comments suppressed due to low confidence (2)
src/Servers/IIS/IntegrationTesting.IIS/src/IISDeploymentParameterExtensions.cs:56
- Inconsistent handling of access elements. In
AddHttpsToServerConfig(lines 36-39), the code now uses a foreach loop to update all access elements, but inAddHttpsWithClientCertToServerConfig(lines 54-56), it still uses.Single()which will fail if there are multiple access elements in a multi-site configuration. This should also be changed to a foreach loop for consistency and to support multi-site scenarios.
element.Descendants("access")
.Single()
.SetAttributeValue("sslFlags", "Ssl, SslNegotiateCert");
src/Servers/IIS/IIS/test/Common.LongTests/ShutdownTests.cs:520
- The removal of
deploymentParameters.HandlerSettings["disallowRotationOnConfigChange"] = "true";changes the test behavior. The test name suggests it verifies that AppHost configuration changes are ignored, but without settingdisallowRotationOnConfigChange, the test now verifies the default behavior where AppHost config changes should be ignored regardless. This makes the test less specific. Consider either updating the test name to reflect the actual behavior being tested or keeping the handler setting to test that the disallow setting works for AppHost config changes too.
var deploymentParameters = Fixture.GetBaseDeploymentParameters(HostingModel.InProcess);
| // need some reasonable delay here to ensure the app has time to react to the file change notification | ||
| // In this case it should ignore it, but it's hard to test that the app doesn't do anything in reaction to the file change. | ||
| for (var i = 0; i < 2000; i++) | ||
| { | ||
| using var res = await deploymentResult.HttpClient.GetAsync("/ProcessId"); | ||
| await Task.Delay(1); | ||
| Assert.Equal(HttpStatusCode.OK, res.StatusCode); | ||
| Assert.Equal(processBefore, await res.Content.ReadAsStringAsync()); | ||
| } |
There was a problem hiding this comment.
The test improvement is good, but there's a potential timing issue. The loop makes 2000 requests with 1ms delay between each (total ~2 seconds). However, if the configuration change takes longer to process, the test might pass even if the app would eventually restart. Consider using a longer total duration or checking the logs to ensure the configuration change was actually processed and ignored.
This comment was marked as spam.
This comment was marked as spam.
|
@fhm20 @bgrmwbys @leepfrog-ger Can you try out the hosting bundle from 11.0-preview2 to see if the issues are resolved and there aren't any other problems? https://dotnet.microsoft.com/en-us/download/dotnet/11.0 using the following command line options to only install ANCM: |
Fixes #58939 and both issues mentioned in #54531, both the empty path issue described in the initial post and the bad shutdown mentioned in #54531 (comment)
These were regressed by #52807
The two regressions were:
disallowRotationOnConfigChangewastruewe would still shutdown the application on config changes.The third fix wasn't a regression but was simple enough to fix and part of one of the issues linked above so included a fix for it. Our usage of
_wcsicmpdidn't properly check the path started with"MACHINE/WEBROOT", it would pass for"", or"MAC","MACHINE/W", etc.We have the test
ConfigurationChangeCanBeIgnoredInProcesswhich should have caught one of the regressions, but since it was testing for the lack of app shutdown it doesn't have any way to know that nothing happened, fixed the test to have a bit of a delay so it has a better chance of failing in the future if we regress this.We also have a multiple application test, but it was only running for IISExpress and it didn't have a restart scenario. Moved the test to the common tests so it's run by IIS as well and added a scenario where 1 of the applications restarts but the others don't.