Skip to content

fix: Make vendored google.protobuf a conditional fallback#1876

Open
gavin-aguiar wants to merge 5 commits into
devfrom
gaaguiar/proto_investigation
Open

fix: Make vendored google.protobuf a conditional fallback#1876
gavin-aguiar wants to merge 5 commits into
devfrom
gaaguiar/proto_investigation

Conversation

@gavin-aguiar

Copy link
Copy Markdown
Collaborator

Description

Make the vendored copy a conditional fallback that only activates when the function app actually ships google.protobuf (the only scenario where the original descriptor-pool conflict can occur).

Detection

A single os.path.isdir check on:
/.python_packages/lib/site-packages/google/protobuf

If present → activate vendored fallback. If absent → do nothing; worker uses its own protobuf + upb.

Activation

When activation triggers:

  1. Set PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python before any vendored module is imported.
  2. Pre-import the vendored modules and alias them into sys.modules under google.protobuf and google.protobuf.internal. Not google itself — that would shadow google.cloud.*, google.auth, google.api_core, etc. (the most common reason a customer ends up with protobuf in their tree in the first place).

The alias propagates to submodules automatically via the parent package's path, so from google.protobuf.timestamp_pb2 import Timestamp correctly resolves to the vendored copy without needing per-submodule aliasing.

Fixes #


Pull Request Checklist

Host-Worker Contract

  • Does this PR impact the host-worker contract (e.g., gRPC messages, shared interfaces)?
    • If yes, have the changes been applied to:
      • azure_functions_worker (Python <= 3.12)
      • proxy_worker (Python >= 3.13)
    • If no, please explain why:

Worker Execution Logic

  • Does this PR affect worker execution logic (e.g., function invocation, bindings, lifecycle)?
    If yes, please answer the following:

Python Version Coverage

  • Does this change apply to both Python <=3.12 and 3.13+?
  • If yes, have the changes been made to:
    • azure_functions_worker (Python <= 3.12)
    • runtimes/v1 / runtimes/v2 (Python >= 3.13)
  • If no, please explain why:

Programming Model Compatibility (for Python 3.13+)

  • Does this change apply to both:
    • V1 programming model (runtimes/v1)?
    • V2 programming model (runtimes/v2)?
  • Explanation (if limited to one model):

hallvictoria
hallvictoria previously approved these changes Jun 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants