Add managedSettings.clearCache RPC bindings (force-clear managed settings cache) - #2438
Add managedSettings.clearCache RPC bindings (force-clear managed settings cache)#2438joshspicer wants to merge 8 commits into
Conversation
Adds the `managedSettings.clearCache` server RPC method across all generated
language clients (TypeScript, C#, Python, Go, Rust, Java).
`managedSettings.clearCache` wipes the persistent enterprise managed-settings
cache for every account and drops the runtime process's in-memory retained
server policy, so the next managed-settings read re-fetches from the network.
It is the primitive behind a host "force refresh account policy" action (e.g.
VS Code's `Developer: Sync Account Policy`).
Consumers call it via the autogenerated RPC wrapper, e.g. in Node.js:
await client.rpc.managedSettings.clearCache();
These files were produced by the standard codegen pipeline
(`scripts/codegen` + `java/scripts/codegen`) run against the current pinned
`@github/copilot` schema baseline with the new method added, so they match
what a post-publish regen will produce. The runtime side lives in
github/copilot-agent-runtime; once that ships and the `@github/copilot`
dependency is bumped to a version exposing `managedSettings.clearCache`,
`codegen-check` reproduces these files exactly.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Auto-committed by java-codegen-check workflow.
github-actions
Bot
added
the
dependencies
This comment has been minimized.
This comment has been minimized.
❌ Automated Fix Unable to Resolve Build FailureThe agentic fix workflow analyzed the failing Root CauseThe build failure is not caused by code generation changes or handwritten SDK/test code. Instead, the failure is caused by an The CI workflow ( What Was Attempted
Why Manual Intervention Is NeededThe fix requires one of:
Both of these files are outside the scope of automated fixes in this workflow. A human maintainer needs to decide whether the JDK 25 requirement is intentional (and the workflow needs updating) or accidental (and the enforcer should be removed/relaxed). The codegen-related changes in this PR (adding Warning Firewall blocked 1 domainThe following domain was blocked by the firewall during workflow execution:
network:
allowed:
- defaults
- "repo.maven.apache.org"See Network Configuration for more information.
|
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Auto-committed by java-codegen-check workflow.
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The checked-in schema cannot reproduce the generated outputs, and the promised Java binding is missing.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review tier: Balanced
Findings: None
What changed in this PR
Adds generated managedSettings.clearCache RPC bindings for force-refreshing enterprise policy caches.
Changes:
- Adds wrappers for TypeScript, C#, Python, Go, and Rust.
- Adds Rust and Go result/method definitions.
| File | Description |
|---|---|
rust/src/generated/rpc.rs |
Adds clear_cache(). |
rust/src/generated/api_types.rs |
Adds the RPC method constant. |
python/copilot/generated/rpc.py |
Adds clear_cache(). |
nodejs/src/generated/rpc.ts |
Adds clearCache(). |
go/rpc/zrpc.go |
Adds result type and ClearCache(). |
dotnet/src/Generated/Rpc.cs |
Adds ClearCacheAsync(). |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…s/update-pr-runtime-clean
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Auto-committed by java-codegen-check workflow.
Cross-SDK Consistency ReviewThis PR adds a new generated RPC method
All five implementations are consistent: same wire method name ( Gap found — Java: No other consistency issues found — this is a clean, generated, cross-language addition.
|
What
Adds the new
managedSettings.clearCacheserver RPC method to the generated TypeScript, C#, Python, Go, and Rust clients.managedSettings.clearCacheforce-refreshes enterprise managed settings for every account by:<cacheHome>/managed-settingsdirectory), andThe method does not fetch policy itself. The next session resolution for an account re-fetches that account's org policy from the network.
managedSettings.readonly returns device/MDM settings and does not trigger an account server-policy fetch, so a host implementing "sync account policy" should start a fresh session resolution rather than treat a subsequentmanagedSettings.readcall as refreshed org policy.This is the primitive behind a host "force refresh account policy" action, such as wiring VS Code's
Developer: Sync Account Policycommand to clear managed policy on demand.Consumers call it through the generated RPC wrapper, for example:
Equivalent methods are
ClearCacheAsync()in C#,clear_cache()in Python and Rust, andClearCache(ctx)in Go.Generation
The bindings were regenerated from the authoritative runtime API schema at
github/copilot-agent-runtime#17809head7ab07b119ba0fe42fe427836dfb2bcd936819082.scripts/codegen.The generated output now matches the runtime contract's current behavior and documentation, including rejection when the on-disk cache cannot be removed.
Dependency ordering
The checked-in bindings are intentionally ahead of the currently pinned
@github/copilotpackage. Once the runtime schema is published and the SDK dependency is bumped, a standard regeneration will reproduce these bindings and generate Java'sclearCache()wrapper. Until then, the Java codegen workflow correctly normalizes Java back to the published schema, so the Java binding is not included in this draft.The PR remains draft/blocked until that package update is available.
Testing
go/rpc.netstandard2.0,net8.0, andnet10.0.mvn verifyand a clean follow-up SDK verification pass against the currently published schema. The locally generatedclearCache()wrapper also compiled successfully before CI normalized it back to that published schema.Full cross-language E2E suites were also exercised. Remaining failures were unrelated environment/runtime-harness issues (replay misses/timeouts, unavailable local .NET 8 testhost, and tests requiring a runnable/authenticated CLI), not generated binding failures.