Skip to content

Enable compiled endpoint rules for all services and fix regionId parameter mismatch bug - #7265

Open
S-Saranya1 wants to merge 3 commits into
masterfrom
somepal/enable-compiled-endpoint-rules-flag-flip
Open

Enable compiled endpoint rules for all services and fix regionId parameter mismatch bug#7265
S-Saranya1 wants to merge 3 commits into
masterfrom
somepal/enable-compiled-endpoint-rules-flag-flip

Conversation

@S-Saranya1

@S-Saranya1 S-Saranya1 commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Motivation and Context

Compiled endpoint rules generate endpoint resolution logic as direct Java code at codegen time, rather than interpreting rules at runtime. This provides ~40% better performance. The feature was behind a flag (enableGenerateCompiledEndpointRules) and already enabled for 344 services externally. This PR enables it for all remaining internal services by flipping the flag to true.

However, simply flipping the flag exposed a bug in the compiled endpoint provider codegen. The resolveEndpoint method extracts the region as a local String variable and always passes it to the root rule method:

Region region = params.region();
String regionId = region == null ? null : region.id();
RuleResult result = endpointRule0(params, regionId);  // always 2 args

But the root rule method's signature is generated based on scope analysis, it only includes regionId as a parameter if that method directly uses it. For most services, the root rule directly uses region (e.g., to look up the partition), so the 2-arg call matches:

private static RuleResult endpointRule0(Params params, String regionId) { ... } // 2 params - works

But for some services, the root rule just delegates to a child rule without using region itself:

private static RuleResult endpointRule0(Params params) { ... } // 1 param - compile error!

This creates a mismatch: the call site passes 2 arguments but the method only accepts 1.

This PR fixes the bug by adding a regionId() method to the endpoint params class that returns the region as a String (null-safe). The codegen now emits params.regionId() wherever the rules need the region as a string, eliminating the local variable and the parameter passing mismatch entirely.

Modifications

  • CustomizationConfig.java — Flip enableGenerateCompiledEndpointRules default from false to true
  • EndpointProviderSpec2.java — Remove region local variable extraction (Region region = params.region(); String regionId = ...) from resolveEndpointMethod(). Update initSymbolTable() to mark region params via addRegionParam() instead of creating a local
  • SymbolTable.java — Replace String regionParamName with Set<String> regionParams. Add isRegionParam() and addRegionParam() methods
  • CodegenExpressionBuidler.java — Remove regionParamName() accessor
  • RenameForCodegenVisitor.java — When the referenced param is a region param, emit params.regionId() (append "Id" to accessor name) instead of params.region()
  • EndpointParametersClassSpec.java — Generate regionId() method for Region-typed params: return region == null ? null : region.id()
  • AuthSchemeParamsSpec.java — Add regionId() default method to the interface
  • DefaultAuthSchemeParamsSpec.java — Add regionId() override
  • EndpointRulesSpecUtils.java — Add directory fallback to rulesEngineResourceFiles2() so compiled rules codegen works when running from exploded classes in test environments

Testing

  • All existing tests pass
  • Golden file tests updated to verify generated code uses params.regionId() pattern
  • Added runtime tests for regionId() (null and non-null cases)
  • Dry-run build to live on build.amazon.com passed for AwsJavaSdk-Codegen

Screenshots (if appropriate)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Checklist

  • I have read the CONTRIBUTING document
  • Local run of mvn install succeeds
  • My code follows the code style of this project
  • My change requires a change to the Javadoc documentation
  • I have updated the Javadoc documentation accordingly
  • I have added tests to cover my changes
  • All new and existing tests passed
  • I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
  • My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

  • I confirm that this pull request can be released under the Apache 2 license

@S-Saranya1
S-Saranya1 requested a review from a team as a code owner August 12, 2026 22:05
@S-Saranya1
S-Saranya1 requested a review from RanVaknin August 12, 2026 22:31
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.

1 participant