[Resolved] Temporary block on non-ASCII package ID uploads

[joelverhagen]

Update April 23, 2025: the temporary block has been reverted. You can now upload non-ASCII package IDs again.

This announcement concerns the package upload feature on NuGet.org. If you do not publish packages to NuGet.org, no
action is needed. If you are a package author using only ASCII characters in your package IDs, you are not affected.

What's changing

Starting Thursday, April 17th, 2025, NuGet.org will temporarily block uploads of packages with non-ASCII characters in
the package ID. This is a short-term mitigation for a bug recently discovered in our publishing pipeline.

We are actively working on a full fix that will restore the ability to create and update packages with non-ASCII IDs. We
apologize for the inconvenience and appreciate your patience.

Why this is happening

The bug prevents packages with non-ASCII IDs from completing the publishing process. These packages get stuck
mid-pipeline and never become available for:

• Package restore (download)
• Package browsing in Visual Studio
• Package search

Resolving these stuck packages requires manual intervention by our on-call team, and can negatively impact other authors
and the overall reliability of our service.

Impact

• Uploading new packages or updates with non-ASCII IDs is temporarily blocked.
• Packages with ASCII-only IDs are unaffected.
• Existing packages (ASCII and non-ASCII) remain available for restore and consumption.

A very small percentage of packages use non-ASCII characters in their IDs, so we believe this mitigation strikes a fair balance
between minimizing disruption and maintaining the health of the service.

Next steps

We will update this post and revert the upload block as soon as the issue is resolved. We anticipate having a fix by the
end of next week (April 25th) but will let the community know as we make progress.

[felsokning]

@joelverhagen - You mention a bug but I can't find reference to it in the Issues section. Does this bug exist, elsewhere - in a publicly accessible place, so that we understand the nature of the bug?

Given that non-ASCII characters have been supported since at least 2015, it would be nice to understand the "what".

You've given the "why", which I can somewhat appreciate (not wanting to be paged because the publishing process is stuck) -- but it would be nice to understand what changed/broke, how it was arrived at after ~10+ years of supporting non-ASCII characters, and (hopefully) how that bug might be prevented in the future.

As someone who has packages with non-ASCII in the title and in the contents, this affects my personal work (publishing, updating, etc.) until the bug is unblocked/resolved; which is why I have a vested interest in understanding the bug.

[joelverhagen]

Hey @felsokning, the bug is in our Db2Catalog job. This job was recently moved to the new Azure SDK. When we did that refactoring, we accidentally introduced a bug which URL encoded non-ASCII characters in the blob name for the catalog leaf document, which contains the ID and version. Since the SDK also URL encodes the blob name for the blob storage REST API, this resulted in double encoding. To be clear this is not a bug with the Azure SDK but instead a bug in our integration.

The double encoding caused a broken link in the catalog page, causing downstream publishing jobs to get stuck, unable to fetch the catalog leaf document needed for processing. We noticed this first in the Catalog2Dnx job which populates the package content endpoint used by NuGet restore.

Other publishing jobs wait on Catalog2Dnx to complete so this results in the the package metadata and package search endpoints not getting updated with new package metadata.

From the package author perspective, the package would complete validation but never be indexed in the search service (which is the last publishing step).

[erdembayar]

@felsokning

Could you please try to publish unicode package? Fix deployment is complete.

[felsokning]

@erdembayar - Can confirm that it's resolved.

[felsokning]

Package shows up, already, in the feed[s]. https://www.nuget.org/packages/Fels%C3%B6kning.RipeStat

[felsokning]

@erdembayar - Did it break, again, by any chance? Seeing this when trying to pull it.

This is the log from the pull attempt:

Restoring packages for C:\Sources\Staging\IpQuery\IpQuery\IpQuery\IpQuery.csproj...
  GET https://api.nuget.org/v3-flatcontainer/felsökning.ripestat/index.json
  NotFound https://api.nuget.org/v3-flatcontainer/felsökning.ripestat/index.json 156ms
  CACHE https://api.nuget.org/v3/vulnerabilities/index.json
  CACHE https://api.nuget.org/v3-vulnerabilities/2025.04.17.23.39.46/vulnerability.base.json
  CACHE https://api.nuget.org/v3-vulnerabilities/2025.04.17.23.39.46/2025.04.24.23.40.07/vulnerability.update.json
NU1101: Unable to find package Felsökning.RipeStat. No packages exist with this id in source(s): C:\Program Files\dotnet\library-packs, Microsoft Visual Studio Offline Packages, nuget.org
Package restore failed. Rolling back package changes for 'IpQuery'.
Time Elapsed: 00:00:00.4193746
========== Finished ==========

[erdembayar]

There could be another layer of bug, I'm investigating now.

[erdembayar]

@felsokning
I believe it's resolved now. I manually installed that package in clean test VM, it restores as expected.

[erdembayar]

https://api.nuget.org/v3-flatcontainer/fels%C3%B6kning.ripestat/index.json