Skip to content

feat(gengapic): add dynamic resource name heuristics#1722

Merged
quartzmo merged 23 commits intogoogleapis:mainfrom
quartzmo:feature/heuristics-integration
Mar 31, 2026
Merged

feat(gengapic): add dynamic resource name heuristics#1722
quartzmo merged 23 commits intogoogleapis:mainfrom
quartzmo:feature/heuristics-integration

Conversation

@quartzmo
Copy link
Copy Markdown
Member

This PR implements fallback heuristics to deduce resource name templates for unannotated legacy services (like Compute Engine).

It is gated behind a new DynamicResourceHeuristicsFeature flag.

The solution is a two-step process:

  1. Scan standard CRUD methods in the API package to learn a vocabulary of valid collection nouns (e.g. projects, topics).
  2. Process URI endpoints against the learned vocabulary to return validated paths as templates.

The learned vocabulary is stored as a new field on the Generator struct so it can be shared across file generation runs without redundant rescans. The implementation includes robust custom verb stripping (e.g. :cancel, :publish), correctly handles interstitial literals like "global", and discards partial matches if variables sitting to the left are not in the vocabulary.

… name fields

Migrate resourceNameField from a single string accessor to a HeuristicTarget struct (containing a format string and field names).

- Why: Standard field getters fail for unannotated legacy paths with multiple variables (e.g., /projects/%s/locations/%s).
- Host Resolution: Resolves the service DefaultHost extension at generator-time instead of runtime to evaluate paths (such as //foo.googleapis.com/%v) without passing host into fmt.Sprintf dynamically.
Implement dynamic resource name heuristics to infer resource name formatting for unannotated services.
- Add BuildHeuristicVocabulary to learn valid collection nouns from standard methods
- Add IdentifyHeuristicTarget to walk backward and infer resource name templates
- Strip custom verbs (e.g. :cancel, :publish) from literals before checking vocabulary
- Add test cases for interstitial literals (e.g. global in Compute Engine)
- Add test coverage for multiple variables and disconnected chains
Comment thread internal/gengapic/generator.go
Comment thread internal/gengapic/gengapic.go Outdated
Comment thread internal/gengapic/gengapic.go Outdated
Comment thread internal/gengapic/heuristics.go Outdated
Comment thread internal/gengapic/heuristics_test.go
Comment thread internal/gengapic/gengapic.go Outdated
Comment thread internal/gengapic/heuristics.go Outdated
…ntext

enable F_open_telemetry_tracing F_open_telemetry_logging and F_open_telemetry_metrics in showcase testing
Copy link
Copy Markdown
Contributor

@westarle westarle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking good, I think we can just tidy things up a little bit by collecting everything in injectTelemetryContext and fixing keys.

Comment thread internal/gengapic/gengapic.go Outdated
Comment thread internal/gengapic/gengapic.go Outdated
Comment thread internal/gengapic/gengapic.go Outdated
Comment thread internal/gengapic/gengapic.go Outdated
Comment thread internal/gengapic/gengapic.go Outdated
Comment thread internal/gengapic/genrest.go Outdated
Comment thread internal/gengapic/genrest.go Outdated
Comment thread internal/gengapic/genrest.go Outdated
Comment thread showcase/showcase.bash Outdated
Copy link
Copy Markdown
Contributor

@westarle westarle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we at least need to fix the keys so it works, tidy up can happen in another PR.

Copy link
Copy Markdown
Contributor

@shollyman shollyman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How much do you care about independent feature enablement at this point? Your implementation looks to be basically OR-checking that any of the three o11y generator features is enabled and emitting shared code (which is then emitting ifFeatureEnabled OR-ing). If they're not easily decoupled just collapse them into a single generator feature.

Similarly, I see you've defined DynamicResourceHeuristicsFeature here and use it in gengapic but I see no tests that turn it on, nor anything that compares what happens with it on or off.

@westarle
Copy link
Copy Markdown
Contributor

westarle commented Mar 31, 2026

How much do you care about independent feature enablement at this point?

Yeah, I think we weren't sure about what data was required for each signal before. It makes sense to consolidate the generator side flags to F_open_telemetry_attributes (and it will be easier to launch).

We must keep IsFeatureEnabled("TRACING") tests independent. Of course we can || the result into a single boolean like any_telemetry_feature_enabled if that is ever helpful.

Copy link
Copy Markdown
Contributor

@shollyman shollyman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot going on here, but I think its LGTM. The unit testing exercises the heuristic, but we don't appear to have any golden output tests that demonstrate the heuristic in practice. My assumption this is coming in a followup.

@quartzmo quartzmo merged commit 9515cd2 into googleapis:main Mar 31, 2026
8 checks passed
@quartzmo quartzmo deleted the feature/heuristics-integration branch March 31, 2026 21:49
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.

3 participants