fix(compute): gate shared operation types behind per-service features - #6312
fix(compute): gate shared operation types behind per-service features#6312raushan728 wants to merge 1 commit into
Conversation
model.rs already feature-gates `Operation`, `operation::Status`, and the two `OperationMetadata` types behind per-service features, but `errors.rs` and `operation.rs` referenced them unconditionally, breaking `--no-default-features` builds. Applying the same gate to both files keeps them consistent with what `model.rs` actually exports. Fixes googleapis#6220
There was a problem hiding this comment.
Code Review
This pull request adds a build test for google-cloud-compute-v1 with --no-default-features and introduces conditional compilation attributes to errors.rs and operation.rs in the generated compute crate. The feedback highlights that directly modifying files in src/generated violates the repository style guide, and these changes should instead be implemented through the generator or its configuration.
| #![cfg(any( | ||
| feature = "accelerator-types", | ||
| feature = "addresses", | ||
| feature = "advice", | ||
| feature = "autoscalers", | ||
| feature = "backend-buckets", |
There was a problem hiding this comment.
This list would need to change every time the generator creates a new feature that enables LROs. That happens automatically, several times a year. We don't want to have to manually edit these files each time.
Ideally, we change the code generator to emit a hidden feature that represents "we need the operation types" and the generator enables that feature when any feature that needs it is enabled. Then this code can be changed once.
There was a problem hiding this comment.
this makes sense long term. I looked into the generator and it already tracks which types are used for long-running
operations, so adding a hidden feature that other features can depend
on looks doable without too much trouble, and it would help the other crates with the same pattern too.
since that change lives in the generator repo, would it be okay to merge this as the immediate fix for the critical build breakage, while open an issue there for the hidden-feature. once that's implemented, I'll follow up here to switch the fix over.
There was a problem hiding this comment.
this makes sense long term. I looked into the generator and it already tracks which types are used for long-running operations, so adding a hidden feature that other features can depend on looks doable without too much trouble, and it would help the other crates with the same pattern too.
Thanks.
since that change lives in the generator repo, would it be okay to merge this as the immediate fix for the critical build breakage,
Hmm... I see this was labeled "critical", but I don't understand why. @dbolduc
while open an issue there for the hidden-feature. once that's implemented, I'll follow up here to switch the fix over.
Frankly I would rather not put this fix in. It creates a maintenance headache, and the workaround for anybody affected by the bug is to enable any feature (say zone-operations) that fixes the build.
model.rs already feature-gates
Operation,operation::Status, and the twoOperationMetadatatypes behind per-service features, buterrors.rsandoperation.rsreferenced them unconditionally, breaking--no-default-featuresbuilds. Applying the same gate to both files keeps them consistent with whatmodel.rsactually exports.Fixes #6220