Composer 1 provider files sometimes end up with 'error' as the sha256

Any thoughts on where to dig-in for hunting this issue?

Marking as critical to match the related issue linked above. Definitely looks like the same problem but the related issue didn't describe the actual fix. Confirming that nothing in the single commit of the release should have caused this, so not something in the module itself.

The module went from a previous RC-2 release to a stable 1.0 release if that matters at all.

Might need to contact @mixologic to learn how this was fixed in the past or if it's just a matter of rerunning the release.

But this is preventing us from updating or installing any module into multiple client projects at this time.

Ditto, went back through the versions as well.

Also, cleared the vendor cache. No luck
Also, rebuilt my fin machines.

I don't have vendor or .lock in any of my repositories.

The upstream maintainer apparently has fixed this by pushing a new release.

The underlying issue here is an apparent race condition that causes the json data that is being saved into the composer 1 provider files to fail when its sent through a shasum (which likely means its empty).

I found three other projects that have been intermittently throwing this error:

mapbox_ui, google_index_api, and die_in_twig.

As well as a couple of distributions that have somehow found their way into the provider files:

seeds, ooyala (d7)

All of these have their most recent release as prior to the major work we did to packages.drupal.org to support composer 2, so that rules out a regression, and that this is, in fact, some form of longstanding bug.

Im going to postpone and retitle, until I can figure out what leads to this race condition (I have a hunch, and a plan that will likely eliminate it)

Thanks for the report.

Confirming, our team's builds are running now.

This is happening with today's Drupal 7 update again. Do we just wait for the upstream provider to fix?

Drupal 7 was a similar but different error.

Still happening and sadly to a security release for D8/D9 this time :/
https://www.drupal.org/project/drupalorg/issues/3195796

Noting another instance of this failure from earlier today.

Today the command composer show "drupal/date" --all gives the error mentioned above.

[Composer\Downloader\TransportException]
  The "https://packages.drupal.org/7/drupal/date%24error.json" file could not be downloaded (HTTP/1.1 404 Not Found)

So, if i understand correctly this could be fixed if the maintainer of the date (d7) module creates a new release and the information on packages.drupal.org would be updated?

Same error here after composer require drupal/date and composer install while drupal/date is under require section.
I think is on drupal/date side. Mentioned here: https://www.drupal.org/project/date/issues/3202258

The composer metadata for date has been rebuilt.

So, if i understand correctly this could be fixed if the maintainer of the date (d7) module creates a new release and the information on packages.drupal.org would be updated?

Any commit to the project should trigger the metadata to be rebuilt, a release is not required.

The drupal/fac security release from March 17 had this issue as well. The release node was unpublished for several hours.

Unfortunately, the maintainer only found out about this on March 19 when they fixed it by making a whitespace commit per the recommendation in #14.