chore(deps): require pi 0.82.1 and port the removed reloadConfig()

Bump @earendil-works/pi-coding-agent, pi-ai, and pi-agent-core to 0.82.1
together and raise the peer range to >=0.82.1 <0.83. All three must move in
lockstep: bumping only two leaves a duplicate pi-ai copy in the tree, which
surfaces as misleading type-identity errors rather than real API breaks.

Pi 0.82 removed ModelRuntime.reloadConfig() and merged it into refresh(),
which now does ModelConfig.load, configureRadiusProviders, and rebuildProviders
before refreshing. Port the five production call sites literally, passing no
options so refresh() keeps defaulting allowNetwork to modelNetworkEnabled --
which the shared runtime pins to false by constructing under PI_OFFLINE. No
call site passes allowNetwork: true.

The auth tests lose reloadConfig() as an observation seam, so the offline
regression cases now drive removeRuntimeApiKey(), the surviving public mutation
that still forwards the construction-time network flag to refresh().
This commit is contained in:
Federico Jaramillo Martinez
2026-07-25 19:09:18 +02:00
parent b445ddae04
commit 20b65cf5b9
6 changed files with 209 additions and 189 deletions
+9 -9
View File
@@ -42,12 +42,12 @@ let offlineRuntimeCreations: Promise<unknown> = Promise.resolve();
/**
* Create the shared model runtime with runtime-owned network refreshes disabled.
*
* Upstream `ModelRuntime.reloadConfig()`, `login()`, and `logout()` always refresh
* with `allowNetwork: modelNetworkEnabled` and accept no abort signal. With the
* default (`PI_OFFLINE` unset) a single stalled provider-catalog fetch can block
* those call paths for minutes — and, because pi-web shares one runtime and pi
* coalesces per-provider refreshes, session creation joins the same stalled
* fetch. Forcing `PI_OFFLINE` during construction makes every runtime-driven
* Upstream `ModelRuntime.refresh()`, `login()`, and `logout()` always refresh
* with `allowNetwork: modelNetworkEnabled` by default, and `login()`/`logout()`
* accept no abort signal. With the default (`PI_OFFLINE` unset) a single stalled
* provider-catalog fetch can block those call paths for minutes — and, because
* pi-web shares one runtime and pi coalesces per-provider refreshes, session
* creation joins the same stalled fetch. Forcing `PI_OFFLINE` during construction makes every runtime-driven
* refresh local-only; pi-web performs its own bounded catalog refreshes in the
* background instead (see modelCatalogRefresher.ts).
*
@@ -122,7 +122,7 @@ export class AuthService {
}
async authProviders(mode: "login" | "logout", authType?: AuthType): Promise<AuthProvidersResponse> {
await this.runtime.reloadConfig();
await this.runtime.refresh();
const providers = mode === "logout" ? await getLogoutProviderOptions(this.runtime) : getLoginProviderOptions(this.runtime, authType);
return { providers };
}
@@ -208,7 +208,7 @@ export class AuthService {
}
private async requireApiKeyLoginProvider(providerId: string) {
await this.runtime.reloadConfig();
await this.runtime.refresh();
const provider = getLoginProviderOptions(this.runtime, "api_key").find((option) => option.id === providerId);
if (provider !== undefined) return provider;
@@ -220,7 +220,7 @@ export class AuthService {
}
private async requireOAuthLoginProvider(providerId: string) {
await this.runtime.reloadConfig();
await this.runtime.refresh();
const provider = getLoginProviderOptions(this.runtime, "oauth").find((option) => option.id === providerId);
if (provider === undefined) throw new Error(`OAuth provider not found: ${providerId}`);
return provider;