Conversation
# Conflicts: # .github/workflows/ci.yml
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. This PR will not appear in the changelog. 🤖 This preview updates automatically when you update the PR. |
| -RedirectStandardError "$PSScriptRoot/results/${Action}-stderr.txt" | ||
|
|
||
| # Run integration test action on device | ||
| $process | Wait-Process -Timeout ($timeoutSeconds + 30) |
There was a problem hiding this comment.
Bug: The Wait-Process -Timeout command will cause an unhandled exception on timeout because $ErrorActionPreference is set to "Stop", crashing the test script.
Severity: MEDIUM
Suggested Fix
Wrap the Wait-Process call in a try/catch block to handle the timeout exception gracefully. Alternatively, override the error handling for this specific command by adding -ErrorAction SilentlyContinue to the Wait-Process call. This will prevent the script from crashing and allow the intended timeout logic to proceed.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: test/IntegrationTest/Integration.Tests.ps1#L52
Potential issue: The script sets `$ErrorActionPreference = "Stop"` globally. When the
`Wait-Process -Timeout` command on line 52 times out, it generates what is normally a
non-terminating error. However, due to the global error preference, this is promoted to
a terminating exception. Because this call is not wrapped in a `try/catch` block, the
script will crash. This prevents graceful timeout handling, subsequent cleanup code from
running, and leads to the test server process leaking resources on the CI runner.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| <!-- Run smoke test on the WebGL player: dotnet msbuild /t:UnitySmokeTestPlayerWebGL src/Sentry.Unity --> | ||
| <Target Name="UnitySmokeTestPlayerWebGL" Condition="'$(MSBuildProjectName)' == 'Sentry.Unity'"> | ||
| <Exec Command="pwsh -Command "Invoke-Pester -Path '$(RepoRoot)test/IntegrationTest/Integration.Tests.WebGL.ps1' -CI"" IgnoreStandardErrorWarningFormat="true"/> | ||
| <Exec Command="pwsh -Command "$$env:SENTRY_TEST_PLATFORM = 'WebGL'; $$env:SENTRY_TEST_APP = '$(PlayerBuildPath)WebGL'; Invoke-Pester -Path '$(RepoRoot)test/IntegrationTest/Integration.Tests.ps1' -CI"" IgnoreStandardErrorWarningFormat="true"/> |
There was a problem hiding this comment.
Shell expansion breaks MSBuild WebGL target on Linux/macOS
Medium Severity
The UnitySmokeTestPlayerWebGL target wraps $$env:SENTRY_TEST_PLATFORM and $$env:SENTRY_TEST_APP inside a double-quoted pwsh -Command string. MSBuild's $$ escaping only protects against MSBuild property evaluation, producing a literal $ in the output. On Linux/macOS, the Exec task invokes /bin/sh, which interprets $env inside the double-quoted string as a shell variable and expands it to an empty string, mangling the PowerShell command into something like :SENTRY_TEST_PLATFORM = 'WebGL'. The old command had no $env: references and worked cross-platform.


Instead of having duplicate integration test scripts for each platform, now that we have them all covered, merge them into one.
#skip-changelog