Skip to content

chore(kiota): regenerate REST clients with Kiota 1.35.0 - #3

Merged
petter merged 1 commit into
mainfrom
chore/kiota-1.35.0
Sep 11, 2026
Merged

petter merged 1 commit into
mainfrom
chore/kiota-1.35.0

Conversation

@petter

@petter petter commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

Why

yarn distribute installs Kiota from generators/generate-sh/toolchain.json. That pin is now 1.35.0. These Java clients were generated with 1.31.1. A regenerate with 1.35.0 writes the same clients the next distribute run will write.

Scope

  • Files under src/main/java/**/generated/, including kiota-lock.json kiotaVersion.
  • Handwritten sources and microsoft-kiota-bundle:1.9.3 stay as they are.

Tradeoffs

The Maven runtime stays at 1.9.3. Listing Management compiled against that runtime after a 1.35.0 regenerate, so a runtime bump is a separate change.

Blast Radius

Partners who compile this SDK pick up Kiota 1.35.0 URL-template and lockfile updates in the generated REST clients. Handwritten wrappers are not in this PR.

Verification

  • kiota --version reported 1.35.0.
  • ./generate.sh completed with that binary on PATH.
  • Every kiota-lock.json in this repository reports kiotaVersion 1.35.0.
  • ./gradlew compileJava --no-daemon succeeded.

Pin the generated REST clients to Kiota 1.35.0 so they match generators/generate-sh/toolchain.json.
The Java runtime stays at com.microsoft.kiota:microsoft-kiota-bundle:1.9.3.
@petter

petter commented Sep 11, 2026

Copy link
Copy Markdown
Contributor Author

PASS+NOTES

Independent verification by an agent that did not write this PR. No code was changed, rebased, or pushed.

SHAs and patch identity

  • Base SHA (merge-base with origin/main): ad28adae19737dfa0bc169c0529917c235ad9153
  • Head SHA: eadffb1e1bbade9fd3f327581677785ea66dc644 (matches the PR head reported by the forge)
  • Stable patch-id of base..head: 5b21ac9c79fecec06e39b8d7ac57bd9702e259af

Scope check

5 changed paths, all modifications, all inside src/main/java/**/generated/. Nothing outside that prefix.

M src/main/java/com/ebay/communication/generated/feedback/feedback/FeedbackRequestBuilder.java
M src/main/java/com/ebay/communication/generated/feedback/kiota-lock.json
M src/main/java/com/ebay/communication/generated/message/kiota-lock.json
M src/main/java/com/ebay/communication/generated/negotiation/kiota-lock.json
M src/main/java/com/ebay/communication/generated/notification/kiota-lock.json

Kiota lock check

All 4 kiota-lock.json files at head report kiotaVersion 1.35.0. No lock file was missed and none lags at 1.31.1.

Build outcome

./gradlew build --no-daemon in a worktree at the PR head exited 0, BUILD SUCCESSFUL. A follow-up ./gradlew clean build --no-daemon also exited 0. The GitHub validate SUCCESS was not used as the verdict.

Notes, none blocking

  1. The build proves compilation and packaging only. The repository has no test sources, so Gradle reports :test NO-SOURCE and :check UP-TO-DATE. No runtime behavior was exercised.
  2. FeedbackRequestBuilder carries a real semantic shuffle, not just a version string. The class-level urlTemplate drops feedback_type and user_id and becomes {+baseurl}/feedback{?feedback_id*,...}. toGetRequestInformation now inlines the previous full template literally, so GET request construction is unchanged. toPostRequestInformation switches from the literal {+baseurl}/feedback to urlTemplate. Since the POST configuration binds no query parameters, the template expands to /feedback, so the emitted POST URL is unchanged. The observable difference is the value of the inherited urlTemplate field itself, which matters only to code that reads it directly.
  3. Codegen was not reproduced locally, because kiota is not installed on the verifying machine. This verifies the committed artifact rather than its reproducibility. Two facts reduce that risk. Every descriptionHash is byte-identical across the diff, so the four specs are unchanged in content, and each descriptionLocation now resolves to a file that exists at head under specs/openapi/. The remaining diff is therefore attributable to the 1.31.1 to 1.35.0 generator bump and the stale spec path, not to a spec edit.

@petter
petter merged commit ccf0f6c into main Sep 11, 2026
1 check passed
@petter
petter deleted the chore/kiota-1.35.0 branch September 11, 2026 14:17
petter added a commit that referenced this pull request Oct 26, 2026
Pin the generated REST clients to Kiota 1.35.0 so they match generators/generate-sh/toolchain.json.
The Java runtime stays at com.microsoft.kiota:microsoft-kiota-bundle:1.9.3.
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