NuGet failing with Response status code does not indicate success: 503 (Service Unavailable)

[jkotas]

Build

https://dev.azure.com/dnceng-public/public/_build/results?buildId=300923&view=results

Build leg reported

Build / Installer Build and Test coreclr windows_x86 Debug / Build

Pull Request

dotnet/runtime#78801

Action required for the engineering services team

To triage this issue (First Responder / @dotnet/dnceng):

• Open the failing build above and investigate
• Add a comment explaining your findings

If this is an issue that is causing build breaks across multiple builds and would get benefit from being listed on the build analysis check, follow the next steps:

1. Add the label "Known Build Error"
2. Edit this issue and add an error string in the Json below that can help us match this issue with future build breaks. You should use the known issues documentation

{
   "ErrorMessage" : "Failed to retrieve information about",
   "BuildRetry": true
}

Release Note Category

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

Release Note Description

Additional information about the issue reported

No response

Report

Build	Definition	Step Name	Console log	Pull Request
874185	dotnet/sdk	Build	Log	dotnet/sdk#44805
2585163	dotnet-sdk	Build	Log
2584809	dotnet-sdk	Build	Log
872760	dotnet/sdk	Build	Log	dotnet/sdk#44938
2584333	dotnet-aspnetcore	Run build.sh	Log	#44785
2582521	dotnet-sdk	Build	Log	#44998
870273	dotnet/runtime	Build	Log	dotnet/runtime#109845
868064	dotnet/aspnetcore	Run build.cmd	Log	dotnet/aspnetcore#58900
868068	dotnet/aspnetcore	Build	Log	dotnet/aspnetcore#58900
868066	dotnet/aspnetcore	Run restore.sh	Log	dotnet/aspnetcore#58900
863020	dotnet/roslyn	Restore	Log	dotnet/roslyn#75719
863024	dotnet/roslyn	Restore	Log	dotnet/roslyn#75788
863018	dotnet/roslyn	Restore	Log	dotnet/roslyn#75792
2576646	dotnet-sdk	Build	Log	#44722
862919	dotnet/sdk	Build	Log	dotnet/sdk#44593
2571095	dotnet-sdk	Build	Log	#44480

Build	Definition	Test	Pull Request
862986	dotnet/performance	x64_nativeaot9.0_micro.Partition2.WorkItemExecution	dotnet/performance#4563
2575834	dotnet-sdk	Microsoft.NET.Pack.Tests.dll.WorkItemExecution	#44715

Summary

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

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=300923
Result validation: ✅ Known issue matched with the provided build.

[andriipatsula]

Updated an ErrorMessage

[jkotas]

Updated an ErrorMessage

This error message is too specific. The package name does not matter for 503 errors. You can see it in the log file attached to this issue. The build failure was caused by multiple different packages failing to be retrieved - for example, look for Failed to retrieve information about 'Microsoft.Build.Tasks.Git'.

[andriipatsula]

Yeh, most probably Failed to retrieve information about pattern should work.

[ulisesh]

15 hits in the last 24 hours, I'm going to enable build retry

[MattGal]

Created IcM to ask for investigation here as well, https://portal.microsofticm.com/imp/v3/incidents/details/353857134/home

[ulisesh]

More hits today.

Update from the IcM: "Will check throttling limits to see if that's kicking in here"

[epananth]

I updated the ICM and received no response from them.

[dougbu]

Where are 500s from the public AzDO feeds tracked❔ I don't see efcore-ci build #20230213.2 mentioned here for example. That build matches the ErrorMessage in the description above.

[ulisesh]

Does the EFCore repo uses build analysis? Known issues tracking is part of build analysis

[dougbu]

Might need a separate Known Build Error for the dotnet-public-npm feed errors we're seeing in dotnet/aspnetcore (a lot). For example,

  error An unexpected error occurred: "https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public-npm/npm/registry/istanbul-lib-report/-/istanbul-lib-report-3.0.0.tgz: Request failed \"500 Internal Server Error\"".
  info If you think this is a bug, please open a bug report with the information provided in "/Users/runner/work/1/s/src/SignalR/clients/ts/common/yarn-error.log".
  info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
  Process stalled
  Active handles:
    - Socket
    - Socket
    - Socket
    - TLSSocket
    - TLSSocket
    - TLSSocket
    - TLSSocket
    - TLSSocket
/Users/runner/work/1/s/eng/targets/Npm.Common.targets(45,5): error MSB6006: "yarn" exited with code 1. [/Users/runner/work/1/s/src/SignalR/clients/ts/common/common.npmproj]
##[error]eng/targets/Npm.Common.targets(45,5): error MSB6006: (NETCORE_ENGINEERING_TELEMETRY=Restore) "yarn" exited with code 1.

Affected aspnetcore-ci rolling builds over the last week:

• #20230211.3
• #20230212.5
• #20230213.40
• #20230214.6

[dougbu]

Does the EFCore repo uses build analysis? Known issues tracking is part of build analysis

No.

/cc @bricelam and @ajcvickers because I don't remember why they didn't opt in and don't know if those reasons remain valid.

[MattGal]

@dougbu this one's on me, the NPM failures you're talking about are #11737. While the IcM for it is unanswered, the known issues system said no repros for a week so I had closed it. Feel free to reactivate. It won't make Azure Devops any more responsive, but it will keep it on our radar.

[dougbu]

Would that issue have picked up the efcore-ci failure given it occurred in a rolling build (where build analysis isn't relevant) for a repo where build analysis isn't enabled anyhow❔

[dougbu]

In any case, the ErrorMessage above means this issue will capture a superset of those tracked in #11737. I'll reopen the other one just because 500 and 503 aren't the same number 😁

[dougbu]

Oh, ignore my last comment. You were talking about the dotnet-public-npm failures. Right @MattGal❔

[dougbu]

Side note: The Known Build Errors infrastructure is tilted pretty far toward PR failures. It's far too manual (AFAICT) to use for rolling build failures and the https://msit.powerbi.com/groups/de8c4cb8-b06d-4af8-8609-3182bb4bdc7c/reports/f0702582-7c04-47ca-a145-6ac37fd25813/ReportSectioncb62e8e5baebca8883e1?experience=power-bi doesn't seem to automatically report matches for such issues (nor help enough in creating them).

[MattGal]

Oh, ignore my last comment. You were talking about the dotnet-public-npm failures. Right @MattGal❔

Correct I was keying off you talking about "pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public-npm/npm/registry/istanbul-lib-report/-/istanbul-lib-report-3.0.0.tgz" since that's not nuget-y

[markwilkie]

Side note: The Known Build Errors infrastructure is tilted pretty far toward PR failures. It's far too manual (AFAICT) to use for rolling build failures and the https://msit.powerbi.com/groups/de8c4cb8-b06d-4af8-8609-3182bb4bdc7c/reports/f0702582-7c04-47ca-a145-6ac37fd25813/ReportSectioncb62e8e5baebca8883e1?experience=power-bi doesn't seem to automatically report matches for such issues (nor help enough in creating them).

@AlitzelMendez - any feedback here?

[epananth]

@ilyas1974 assigning this to you, cos you were looking at a similar issue

[AlitzelMendez]

Side note: The Known Build Errors infrastructure is tilted pretty far toward PR failures. It's far too manual (AFAICT) to use for rolling build failures and the https://msit.powerbi.com/groups/de8c4cb8-b06d-4af8-8609-3182bb4bdc7c/reports/f0702582-7c04-47ca-a145-6ac37fd25813/ReportSectioncb62e8e5baebca8883e1?experience=power-bi doesn't seem to automatically report matches for such issues (nor help enough in creating them).

@AlitzelMendez - any feedback here?

so after some months I saw this comment :) I think we explored this option in the past but I never found the dashboard in which we wanted to add a link to create known issue, but I think is a great and reasonable idea. reopening: #8794