[Linux-arm64] ModuleNotFoundError: No module named 'requests'

[EgorBo]

Widespread failures on linux-arm64

Build Information

Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=935169
Build error leg or test failing: Common.Tests.WorkItemExecution
Pull request: dotnet/runtime#111985

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "ModuleNotFoundError: No module named 'requests'",
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=935169
Error message validated: [ModuleNotFoundError: No module named 'requests']
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 2/3/2025 5:46:15 PM UTC

Report

Build	Definition	Test	Pull Request
935169	dotnet/runtime	Methodical_do.WorkItemExecution	dotnet/runtime#111985

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	1	1

Release Note Category

• Feature changes/additions
• Bug fixes
• Internal Infrastructure Improvements

Release Note Description

Updated Helix Python code for Docker testing on Linux VMs to avoid problems with running python3 reporter/run.py after user/test code executes. Also cleaned up that code as well as our internal queue validation script.

Report

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	0

Release Note Category

• Feature changes/additions
• Bug fixes
• Internal Infrastructure Improvements

Release Note Description

Updated Helix Python code for Docker testing on Linux VMs to avoid problems with running python3 reporter/run.py after user/test code executes. Also cleaned up that code as well as our internal queue validation script.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[jkotas]

Related/duplicate #4756

cc @dougbu

[dougbu]

our rollout revert should clean this problem up. I now suspect the root cause of the new problems is a permissions issue specific to Docker test scenarios

once the revert is done, we'll be heads down trying to figure out how to roll out w/o causing this problem again. @richlander I bet that'll at least temporarily leave the azurelinux.3.amd64* queues busted when used w/ most Helix Docker images

background here is I now suspect a permissions issue rather than set -e. I'm looking around to confirm my suspicions…

[richlander]

This break seems to be calling for a pre-flight/staging approach. We should be able to roll these VM updates out pretty fearlessly. That doesn't seem to be the case.

[jkotas]

our rollout revert should clean this problem up

Yes, it did.