pulumi: No upper bound on python dep protobuf results in latest protobuf version breakage (protobuf>=4.21.0)

What happened?

I was deploying a new stack when I reached a long traceback that ultimately ended with a protobuf error:

File "/opt/hostedtoolcache/Python/3.9.12/x64/lib/python3.9/site-packages/google/protobuf/descriptor.py", line 560, in __new__
          _message.Message._CheckCalledFromGeneratedFile()

Log: https://github.com/CouncilDataProject/denver/runs/6604387518?check_suite_focus=true

Steps to reproduce

I can’t think of a minimal reproducible example at the given moment…

Expected Behavior

Infrastructure deploy to proceed without fail. This same stack configuration completed just fine just hours prior: https://github.com/CouncilDataProject/portland/runs/6597117332?check_suite_focus=true

When I ran a text diff against the two install lists, the only difference between the installed Python packages was protobuf-3.20.1 (succeeding) and protobuf-4.21.0 (failing)

Actual Behavior

Until latest version of protobuf is supported, install should use protobuf>=3.6,<4.21.0 and succeed.

Versions used

OS: Ubuntu 20.04.4 Python: 3.9.12 Pulumi (Python): 3.33.1 pulumi/actions: 3.33.1

Full Python package installed:

Successfully installed aiohttp-3.8.1 aiosignal-1.2.0 arpeggio-1.10.2 async-timeout-4.0.2 attrs-21.4.0 cachetools-5.1.0 cdp-backend-3.0.16 certifi-2022.5.18.1 charset-normalizer-2.0.12 dataclasses-json-0.5.7 decorator-5.1.1 dill-0.3.5.1 fireo-1.5.0 frozenlist-1.3.0 fsspec-2022.5.0 gcsfs-2022.5.0 google-api-core-2.8.0 google-auth-2.6.6 google-auth-oauthlib-0.5.1 google-cloud-core-2.3.0 google-cloud-firestore-2.3.4 google-cloud-storage-2.3.0 google-crc32c-1.3.0 google-resumable-media-2.3.3 googleapis-common-protos-1.56.1 grpcio-1.46.3 grpcio-status-1.46.3 idna-3.3 marshmallow-3.15.0 marshmallow-enum-1.5.1 multidict-6.0.2 mypy-extensions-0.4.3 oauthlib-3.2.0 packaging-21.3 parver-0.3.1 proto-plus-1.20.4 protobuf-4.21.0 pulumi-3.33.1 pulumi-gcp-6.24.0 pulumi-google-native-0.19.1 pyasn1-0.4.8 pyasn1-modules-0.2.8 pyparsing-3.0.9 pyyaml-6.0 requests-2.27.1 requests-oauthlib-1.3.1 rsa-4.8 semver-2.13.0 six-1.16.0 typing-extensions-4.2.0 typing-inspect-0.7.1 urllib3-1.26.9 yarl-1.7.2

Additional context

Looks like this was unpinned in https://github.com/pulumi/pulumi/pull/9337

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you’ve opened one already).

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 6
  • Comments: 17 (10 by maintainers)

Commits related to this issue

Most upvoted comments

Folks, we are working on a release to mitigate this issue!

This is back. Just hit it in our env. I also see Protobuf 4.21.0 is back on pypi.

Folks we are looking into this immediately - thanks for raising the issue! We see the same problem on some of our nightly acceptance test runs

@denniswebb patched version v3.33.2 has been pushed

I have reran my infrastructure deploy job after the protobuf release was yanked and it worked (https://github.com/CouncilDataProject/denver/runs/6613594089?check_suite_focus=true). So for the time being we are seemingly okay but definitely something to pin for the future it seems.

Thanks all for the fast response ❤️

Would it be possible to quickly push out the fix that just pins the version to <4 and work on the larger upgrade of protoc afterward?

We looked into that but setting the pinned version still caused a whole load of our test to fail with the same issue. We have multiple engineers investigating multiple approaches to fix this.

Just adding to this, same issue.

Current workaround is pinning protobuf==3.20.1 in my requirements.txt

Some additional error messages:

If this call came from a _pb2.py file, your generated code is out of date and must be regenerated with protoc >= 3.19.0.
If you cannot immediately regenerate your protos, some other possible workarounds are:
 1. Downgrade the protobuf package to 3.20.x or lower.
 2. Set PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python (but this will use pure-Python parsing and will be much slower). 

https://developers.google.com/protocol-buffers/docs/news/2022-05-06#python-updates

This might be related to generate.sh ?