Protobuf Descriptors cannot be created directly: identify the generated code's owner

Scope and symptoms

Older generated Python message code can conflict with its runtime. Locate the package carrying that code before changing every Protobuf consumer in the environment.

Search fragments; wording and context vary:

Descriptors cannot be created directly

Source-supported context

The 2022 Python update says the upb-based 4.21 runtime required Python code generated by protoc 3.19.0 or newer; that historical transition explains many old _pb2.py descriptor errors, but not every current Protobuf failure. The current cross-version guarantee distinguishes generated code from its runtime: newer generated code must not run against an older runtime. Python has a longer compatibility window than most languages for code generated since 3.20.0, subject to its stated limits and future warnings. Check the exact generated-code producer and runtime pair instead of applying the 2022 workaround to every environment.

Distinguish these cases

1. A dependency carries an old _pb2.py generated before the upb transition and incompatible with the selected Python runtime.

2. A wrapper vendors or copies generated code from another project/revision, or newer generated code is paired with an older runtime.

3. A field/data/interface failure is being grouped with this specific descriptor-construction error merely because Protobuf appears in the stack.

Suggested diagnostic sequence

This sequence is editorial guidance, not a diagnosis of your machine.

1. Preserve the full traceback and locate the first relevant _pb2.py file. Record its owning distribution or node revision, the generated-code header/version if present, the affected Python executable and google.protobuf.__version__; the final line alone cannot identify the producer.

2. Compare that producer's supported runtime range with the installed runtime and the official cross-version rules. Prefer a maintained producer release with compatible generated code; do not hand-edit _pb2.py or replace the whole ComfyUI runtime on the basis of one traceback.

3. For definitions you own, regenerate with a supported protoc/plugin and runtime pairing, then test in a recoverable copy. For third-party generated files, use the owner's maintained fix; if a legacy pairing is required, isolate it and verify every affected consumer.

4. Import the owning generated module, test a minimal real message round trip and the original node, then regress other Protobuf consumers. Record any temporary implementation switch or version constraint with its exact scope and rollback plan.

Completion checks

Generated code loads under the chosen runtime, real message handling and the node call succeed, and related consumers remain consistent.

Limits and cautions

The historical error text may mention protobuf 3.20.x or the pure-Python implementation as temporary workarounds. Neither is a universal repair: the latter can be slower and a shared-environment downgrade can violate other consumers' requirements. No user protocol files or models were executed for this review.

Source review: 2026-09-26. No package installation, generated-code run, GPU inference or user-environment repair was executed.

Original sources

• Protobuf Python update of 2022-05-06 · 2026-09-26
• Cross-version runtime guarantee · 2026-09-26

Related guides

• ModuleNotFoundError in ComfyUI even though the package is installed
• Keep a reproducible ComfyUI repair record without exposing secrets