You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "UncertaintyDeterminesYou4ndMe (via GitHub)" <gi...@apache.org> on 2026/08/22 06:26:09 UTC
[PR] fix(cli): let the TUI wizard create custom relay connections [maka]
UncertaintyDeterminesYou4ndMe opened a new pull request, #3467:
URL: https://github.com/apache/maka/pull/3467
## Summary
The TUI setup wizard (`/setup` and first-run) could not create any of the three custom relay providers — Desktop could. Two gaps, as diagnosed in the issue: the catalog filtered out every provider without a built-in base URL, and the onboarding protocol had no field to carry an endpoint even if they were listed. Per the archaeology in the issue thread, the filter was an explicit phase-1 scope cut in #1254 whose phase-2 base-URL step never landed.
This implements the issue's proposed boundary:
1. `listApiKeyOnboardableProviders()` now lists the `category: 'custom'` relays; `requiresBaseUrl` tells the wizard to collect an endpoint. Providers whose endpoint is derived rather than user-supplied stay excluded — `cloudflare-workers-ai` also has an empty registry `baseUrl`, but it interpolates an account id into a URL template, and Desktop deliberately keeps it out of the base-URL field too; a naive `!baseUrl` unfilter would have offered it a relay prompt it cannot use.
2. The wizard gains a base-URL step between provider pick and API key for `requiresBaseUrl` providers (relays show a 4-step flow, everything else keeps its 3 steps). Input is validated in place with the same rules the Host enforces (http/https, no credentials/query/fragment, 2048-byte cap), so mistakes fail with a readable message instead of a protocol decode error. Blank input is allowed only when a connection already exists — it reuses the persisted endpoint, mirroring the blank-key-reuses-stored-secret pattern.
3. `connection.onboarding.verify`/`save` carry an always-present `baseUrl: string | null` (exact-record wire style, like `apiKey`). A non-null value goes through the shared catalog normalizer (`normalizeCatalogConnectionBaseUrl`; a provider-default value collapses to null). A relay with no endpoint from input, existing connection, or registry is rejected with the new `base_url_not_configured` reason before any network probe. Since the input shapes and result unions are closed wire schemas, `RUNTIME_HOST_COMPATIBILITY_EPOCH` moves to 37 so a mixed pair fails the handshake instead of tearing down the session on the first `/setup`.
4. Discovery runs against the supplied endpoint, and `commitConnectionOnboarding` persists it: the journaled onboarding intent gains the field (allowed-but-not-required on read, so an intent journaled by an older build still replays as "no override"), and `prepareOnboardingUpsert` resolves `input ?? previous ?? registry default`. Two consistency rules ride along: the no-change early-return also compares the base URL so a URL-only change still commits, and a swapped endpoint drops `relayModelProfiles` and the last test result — the same endpoint-keyed contract `applyConnectionUpdate` already enforces, so a new relay does not inherit capability declarations or a "verified" badge from the relay it replaced.
Saving a relay updates the same derived-slug connection Desktop manages, so both surfaces stay in sync.
Fixes #3405
## Verification
- `npm --workspace @maka/runtime-host run test` — 1064 pass / 0 fail
- `npm --workspace @maka/storage run test` — 864 pass / 0 fail (14 pre-existing skips)
- `npm --workspace maka-agent run test` (CLI) — 358 pass / 0 fail
- `npm --workspace @maka/desktop run typecheck` + tests — clean, 1038 pass (desktop consumes the changed protocol types; it has no onboarding-operation callers)
- `biome check` on all changed files — clean; `knip` output byte-identical to `main`
New tests (kept deliberately light — five additions, each pinning one contract):
- protocol: verify/save round-trip with the new field, plus two invalid-URL negatives; the epoch-37 pin alongside the existing epoch ladder
- coordinator, end to end through real stores: a relay with no endpoint is rejected `base_url_not_configured` before any probe; a supplied endpoint reaches discovery and persists; a blank re-verify reuses the persisted endpoint; a re-onboarding that swaps the URL persists it and drops the old relay's profile table
- storage: the onboarding-intent journal round-trips the endpoint, and a journal written by a build that predates the field still replays (crash-recovery compatibility)
- TUI runner, end to end: filtering to a relay inserts the base-URL step (`2/4`), a malformed endpoint is rejected in place, and the endpoint threads through both `verify` and `save`
An independent adversarial review pass probed the change with running experiments before submission; it surfaced five defects — the missing compatibility-epoch bump, the `cloudflare-workers-ai` scope leak, stale endpoint-keyed state surviving a URL swap, a missing local byte cap, and two formatter misses — all fixed and re-verified above, with its blank-reuse/crash-replay/normalizer/state-machine probes coming back clean. Details in the review-record comment on this PR.
## AI use
Select exactly one:
- [ ] No generative tool made a substantive contribution
- [x] Generative tooling made a substantive contribution
Tool(s) and scope: Claude Code implemented the fix across the protocol/coordinator/storage/TUI layers, wrote the tests, and ran the verification; an independent adversarial review pass (also Claude) probed the change with fault-injection experiments and its findings were fixed before submission. I reviewed and verified the result.
## Checklist
- [x] Tests cover the change and fail without it
- [x] Lint, format, typecheck and the affected suites pass locally
Does this PR entail a change in behavior?
- [x] Yes — described under Summary above
- [ ] No
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "UncertaintyDeterminesYou4ndMe (via GitHub)" <gi...@apache.org>.
UncertaintyDeterminesYou4ndMe commented on PR #3467:
URL: https://github.com/apache/maka/pull/3467#issuecomment-5386502500
Rebased a third time — `main`'s epoch line is a hot spot and #3602 minted **42** (`provider_capacity` retry reason) a few hours after my last push, which collided with this PR's 42. New head `def0ab4ab`: the onboarding shapes now take **epoch 43**, comment ladder and floor test updated accordingly. One nuance worth flagging for review: this time git auto-merged the epoch *constant* line (both sides read `42`) and only conflicted on the comments — the numeric collision had to be caught and lifted by hand, which is exactly the mixed-shape hazard the epoch exists to prevent.
Verification on this head: clean rebuild, storage 901/0, CLI 406/406, runtime-host onboarding + protocol suites 65/65, biome clean on the full diff, ASF header audit clean.
@Astro-Han this PR only ever conflicts on the epoch line, and each cycle costs a maintainer CI approval — if it goes stale again before review, I'm happy to keep rebasing, but if you have a review window it may be cheaper to look at this head while it's fresh.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "M4n5ter (via GitHub)" <gi...@apache.org>.
M4n5ter commented on code in PR #3467:
URL: https://github.com/apache/maka/pull/3467#discussion_r3839516386
##########
packages/runtime-host/src/server/connection-effect-coordinator.ts:
##########
@@ -196,8 +198,8 @@ export class HostConnectionEffectCoordinator {
#saveOnboarding(
input: ConnectionOnboardingSaveInput,
): Promise<OperationOutcome<'connection.onboarding.save'>> {
- const slug = deriveConnectionSlug(input.providerType);
- return this.#admit(slug, 'connection.onboarding.save', async () => {
+ const lane = input.connectionId ?? deriveConnectionSlug(input.providerType);
+ return this.#admit(lane, 'connection.onboarding.save', async () => {
const prepared = await this.#discoverOnboarding(input);
Review Comment:
<details open>
<summary>English</summary>
[P2] Bind discovery and commit to the same connection revision, endpoint, and credential basis.
`#discoverOnboarding()` reads the connection and stored credential, then performs remote model discovery before `runMutation()` is acquired. It returns only the supplied-secret marker and discovered models. During that await, a supported catalog/vault mutation can change the same connection. The final commit re-reads the latest state, so `baseUrl: null` preserves the new endpoint and `suppliedSecret: null` preserves the new credential while committing models discovered from the old pair.
I reproduced this through the production coordinators: discovery paused after observing placeholder key A at relay A; a concurrent policy update moved the same connection to relay B and placeholder key B; discovery then returned `model-from-relay-a`. Save reported `saved`, but persisted relay B/key B with relay A's model inventory.
The admission lane covers only this connection-effect coordinator, and the activation gate covers only the final commit; neither revalidates the discovery basis. Please issue a ticket containing the connection revision, effective base URL, and credential basis before discovery, then atomically revalidate it at commit (the existing model-fetch/test ticket pattern is a suitable shape). Add this race as a regression test.
</details>
<details>
<summary>中文</summary>
[P2] 请把模型发现与最终提交绑定到同一个连接 revision、endpoint 和凭证依据。
`#discoverOnboarding()` 会先读取连接和已保存凭证，再在取得 `runMutation()` 之前执行远程模型发现；它返回时只带“是否提供新密钥”的标记和模型列表。在这段 await 期间，受支持的 catalog/vault 更新可以修改同一连接。最终提交会重新读取最新状态，因此 `baseUrl: null` 会保留新 endpoint，`suppliedSecret: null` 会保留新凭证，却把旧 endpoint/凭证发现出的模型一起提交。
我通过生产 coordinator 复现了这一点：模型发现在看到 relay A 和占位密钥 A 后暂停；并发 policy 更新把同一连接改到 relay B 并轮换为占位密钥 B；随后发现返回 `model-from-relay-a`。保存返回 `saved`，但最终持久化的是 relay B/密钥 B 加 relay A 的模型清单。
当前 admission lane 只覆盖这个 connection-effect coordinator，activation gate 也只覆盖最后一次提交；两者都不会重新验证发现依据。请在发现前签发包含连接 revision、实际 base URL 和凭证依据的 ticket，并在提交时原子复核（现有 model-fetch/test ticket 模式已经提供了合适形状）。同时把这个竞态加入回归测试。
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "UncertaintyDeterminesYou4ndMe (via GitHub)" <gi...@apache.org>.
UncertaintyDeterminesYou4ndMe commented on PR #3467:
URL: https://github.com/apache/maka/pull/3467#issuecomment-5390052704
Both findings addressed on head `bbe7af770` (rebased onto `main@3bb645e99`):
- **[P1]** epoch is now **45** (> main's 44), assigned after the rebase per your instruction; floor test and comment ladder updated.
- **[P2]** onboarding now uses a begin/complete ticket that binds discovery to the connection revision, credential basis, and pinned effective proxy, revalidated atomically at commit — details and the adversarial verification matrix in the inline reply; the reviewed race is regression-tested end to end.
Local verification: storage 908/0, runtime-host 1123/0, CLI 424/424, desktop typecheck clean, biome + ASF header audit clean. The branch is conflict-free against that main; ready for CI approval on this head.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "UncertaintyDeterminesYou4ndMe (via GitHub)" <gi...@apache.org>.
UncertaintyDeterminesYou4ndMe commented on PR #3467:
URL: https://github.com/apache/maka/pull/3467#issuecomment-5384632494
## Adversarial review record — identity-targeting increment (de626752e)
The connection-identity change was probed by an independent review pass with experiments against the real storage stack before pushing. Two defects found and fixed in the pushed head, one pre-existing issue documented:
**Fixed:**
1. **Epoch 37 reuse (blocker).** The earlier commit on this PR minted epoch 37 for the `baseUrl` shape; adding required `connectionId` under the same 37 would let two mutually-undecodable frame shapes handshake successfully and then die at frame decode — exactly what the epoch exists to prevent, and epoch-37 builds exist from this PR's own review cycle. The identity shape now takes **epoch 38**, pinned by its own protocol test.
2. **`connection_not_found` rendered as a key error.** The runner wrapped every verify rejection in "API key 验证失败：…请检查后重新输入" — self-contradictory for a rejection retyping can never fix. Stale-snapshot rejections now render unwrapped.
**Verified safe (with running experiments):**
- By-id upsert with a canonical-slug squatter of another provider type: the custom relay edits in place, the squatter is untouched — strictly better than the previous `slug_conflict`. `defaultTarget` seeds at the edited connection and a pruned default releases to null rather than dangling.
- Concurrent delete mid-discovery → `connection_not_found`, orphan credential swept, **no stray connection created** — the exact duplicate this change exists to prevent.
- Wizard state: an abandoned relay pick leaks no `connectionId` into the next provider's verify; a disabled sole connection re-onboards consistently with the canonical path's existing semantics; retired provider types can never be latched (none are listed).
- Admission-lane key change (identity when supplied) aligns onboarding with `connection.models.fetch`'s existing keying; the storage lane serializes commits either way, and the CLI is the only `connection.onboarding.*` client.
- Protocol negatives: empty/whitespace/oversized/missing `connectionId` all reject (old-client shapes cannot decode past the epoch gate); the storage-internal `target_missing` never leaks onto the wire.
**Pre-existing, documented not fixed:** crash-recovery treats a non-convergent onboarding intent as fatal (`invalid_document` → the store cannot open). The review reproduced the same brick through an untouched path (canonical row deleted and re-created out-of-band while an intent names the old id), so the class predates this PR; reaching it requires a hard kill plus an out-of-band catalog edit. A follow-up could treat an id/slug-conflicting intent as obsolete and clear it instead of throwing — happy to file an issue if maintainers agree.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on code in PR #3467:
URL: https://github.com/apache/maka/pull/3467#discussion_r3840520569
##########
packages/runtime-host/src/server/connection-effect-coordinator.ts:
##########
@@ -212,35 +215,48 @@ export class HostConnectionEffectCoordinator {
if (!providerAuthSupportsApiKey(input.providerType)) {
return { kind: 'rejected', reason: 'provider_unsupported' };
}
- const slug = deriveConnectionSlug(input.providerType);
- const catalog = await this.#stores.connectionCatalog.getSnapshot();
- const candidate = catalog.connections.find((connection) => connection.slug === slug);
- if (candidate && candidate.providerType !== input.providerType) {
+ // The begin/complete ticket pair binds this discovery to the connection
+ // revision, credential, and proxy it observed: a concurrent policy update
+ // between the remote probe and the commit supersedes the save instead of
+ // pairing the new endpoint with an inventory it never produced. Verify
+ // simply abandons its ticket (they are WeakMap-held one-shots).
+ const begun = await this.#stores.operations.beginConnectionOnboarding({
+ providerType: input.providerType,
+ connectionId: input.connectionId,
+ });
+ if (begun.kind === 'target_missing') {
+ // Identity supplied by the client names a connection that is gone or
+ // changed provider type: reject instead of deriving a duplicate.
+ return { kind: 'rejected', reason: 'connection_not_found' };
+ }
+ if (begun.kind === 'slug_conflict') {
return { kind: 'rejected', reason: 'slug_conflict' };
}
+ const candidate = begun.connection ?? undefined;
const supplied = input.apiKey?.trim() ?? '';
- const stored = candidate
- ? await this.#stores.operations.exportCredentialMaterial({
- scope: 'connection',
- connectionId: candidate.connectionId,
- kind: 'api_key',
- })
- : null;
- const secret = supplied || stored?.secret || '';
+ const secret = supplied || begun.storedSecret || '';
if (PROVIDER_DEFAULTS[input.providerType].authKind === 'api_key' && secret.length === 0) {
return { kind: 'rejected', reason: 'credential_not_configured' };
}
- const proxy = await this.#stores.operations.resolveNetworkProxyExecution();
- if (proxy.kind !== 'ready') return { kind: 'failed', errorClass: 'network' };
+ // Mirrors the blank-key contract above: a null baseUrl reuses the
+ // existing connection's persisted endpoint or the registry default.
+ // A relay provider with no endpoint from any of those sources cannot
+ // run discovery — reject up front instead of probing an empty URL.
+ const base = candidate
+ ? { ...candidate, ...(input.baseUrl ? { baseUrl: input.baseUrl } : {}) }
+ : transientConnection(input.providerType, input.baseUrl);
+ if (!base.baseUrl && !PROVIDER_DEFAULTS[input.providerType].baseUrl) {
+ return { kind: 'rejected', reason: 'base_url_not_configured' };
+ }
+ // The ticket's basis certifies this exact proxy, so discovery must use
+ // the pinned value rather than re-resolving it (a flip-and-restore
+ // between the two reads would otherwise slip past the basis check).
+ if (begun.proxyCredentialMissing) return { kind: 'failed', errorClass: 'network' };
const transport = this.#createTransport(
- toRuntimePolicyProxy(proxy.networkProxy, proxy.secretMaterial.networkProxy?.secret),
+ toRuntimePolicyProxy(begun.networkProxy, begun.proxySecret ?? undefined),
);
try {
- const effect = await this.#runModelDiscovery(
- candidate ?? transientConnection(input.providerType),
- secret,
- { fetch: transport.fetch },
- );
+ const effect = await this.#runModelDiscovery(base, secret, { fetch: transport.fetch });
Review Comment:
[P2] Onboarding discovery loses the connection's custom request headers and body overlay.
This path probes the provider with the bare transport fetch:
```ts
const effect = await this.#runModelDiscovery(base, secret, { fetch: transport.fetch });
```
The ordinary models path in this same file wraps the transport before handing it over (`:393-400`):
```ts
const requestHeaders = prepared.secretMaterial.requestHeaders
? parseRequestHeaders(prepared.secretMaterial.requestHeaders.secret)
: {};
return await run(
createRequestCustomizationFetch(transport.fetch, {
headers: requestHeaders,
bodyOverlay: prepared.connection.requestBodyOverlay,
}),
secret,
);
```
So a connection that authenticates through a custom header (or needs a body overlay) verifies and saves fine through `models.fetch` and the connection test, but fails during onboarding/re-onboarding: the probe goes out without the header and without the overlay. A run against the production coordinator with real stores reproduces it — the normal path carries the configured header and merges the overlay, the onboarding path carries neither and the provider rejects the request.
The existing re-onboarding tests only cover endpoint and API-key reuse, so nothing catches this. Suggest routing `#discoverOnboarding` through the same customization wrapper (using the ticket-pinned basis it already holds), plus a test with a header-authenticated connection.
<details>
<summary>中文</summary>
onboarding 的 discovery 直接用了裸的 `transport.fetch`，而同文件里正常的 models 路径（`:393-400`）会先套 `createRequestCustomizationFetch`，把自定义请求头和 `requestBodyOverlay` 带上。结果是：靠自定义头鉴权的连接在 `models.fetch` 和连接测试里正常，但走 onboarding/重新 onboarding 时会因为丢头、丢 overlay 而鉴权失败。现有的重新 onboarding 测试只覆盖了 endpoint 和 API key 的复用，抓不到这条。建议让 `#discoverOnboarding` 复用同一个包装（用它已经持有的 ticket 基准），并补一个自定义头鉴权连接的测试。
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on PR #3467:
URL: https://github.com/apache/maka/pull/3467#issuecomment-5384765734
Hi — this PR **conflicts with current `main`** and cannot be merged as-is.
I tested a rebase onto current `main` locally (in a throwaway worktree — your branch was not touched). It stops on these files:
- `packages/runtime-host/src/__tests__/protocol.test.ts`
- `packages/runtime-host/src/protocol/index.ts`
These are real source conflicts, so they need your judgement rather than a mechanical rebase — please rebase onto current `main` and resolve them yourself, then push. Once the branch is conflict-free and CI is green on the new head, I will pick it up for review.
```
git fetch upstream && git rebase upstream/main
# resolve, then
git push --force-with-lease
```
Thanks for the contribution — happy to help if any conflict is unclear.
---
*AI-assisted maintenance note, not a review. It does not count as the required human review under `CONTRIBUTING.md` §Review.*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "UncertaintyDeterminesYou4ndMe (via GitHub)" <gi...@apache.org>.
UncertaintyDeterminesYou4ndMe commented on PR #3467:
URL: https://github.com/apache/maka/pull/3467#issuecomment-5384910281
Rebased onto current `main` (`e05308be7`) and force-pushed with lease; the branch is conflict-free (`d1fe0c826`).
Both conflicts were the compatibility epoch: `main` has moved to **39** (37 = catalog search term, 38 = retired `execute` mode, 39 = Client Capability progress), so this PR's two onboarding epochs collided. Resolution: since neither onboarding shape was ever published separately outside this PR's own review cycle, the `baseUrl` + `connectionId` input requirements and the `base_url_not_configured` / `connection_not_found` rejections now land together as **epoch 40**, with one floor test (`> 39`) added to the existing ladder in `protocol.test.ts` following main's floor-assertion convention.
Also picked up in the rebase: the new storage test file gained the ASF license header main's audit gate now requires (`scripts/asf-license-headers.mjs check` is clean on the head).
Local verification on the rebased head (Node 24.18): storage 900 pass / 0 fail, CLI 393/393, desktop 1243/1243 + typecheck clean, biome clean on the full diff vs main. runtime-host's onboarding/protocol suites pass; its `host-kernel` `bounded election does not launch a Candidate…` test is flaky on my machine (passes 1 in 3 with drifting actual values — `starting`/`recovering`; it exercises #3512's election deadline and this branch does not touch that code). The `@maka/ui` `composer-plus-menu` failure on my machine reproduces on sources byte-identical to main (this PR touches neither `packages/ui` nor `packages/core`), so both look environmental — CI on this head is the authority; ready for it to run.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "M4n5ter (via GitHub)" <gi...@apache.org>.
M4n5ter merged PR #3467:
URL: https://github.com/apache/maka/pull/3467
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "M4n5ter (via GitHub)" <gi...@apache.org>.
M4n5ter commented on code in PR #3467:
URL: https://github.com/apache/maka/pull/3467#discussion_r3839810032
##########
packages/runtime-host/src/protocol/index.ts:
##########
@@ -91,7 +91,10 @@ export const RUNTIME_HOST_REGISTRATION_SCHEMA_VERSION = 1 as const;
export const RUNTIME_HOST_PROTOCOL_VERSION = 0 as const;
// Increment when the same protocol version no longer guarantees safe Client-Host
// interoperability. Mismatches are rejected before domain commands are admitted.
-export const RUNTIME_HOST_COMPATIBILITY_EPOCH = 42 as const;
+export const RUNTIME_HOST_COMPATIBILITY_EPOCH = 43 as const;
Review Comment:
<details open>
<summary>English</summary>
[P1] Rebase and keep the compatibility epoch monotonic against current `main`.
This exact head advertises epoch 43 for required `connectionId`/`baseUrl` onboarding inputs and new closed rejection variants, while current `main` is already epoch 44. These are genuinely incompatible shapes: older exact-record decoders reject the added required fields and closed-union values, so a compatible-change declaration cannot exempt them.
The merge-result guard evaluates base=44/head=43 as `went backward` before it even considers changed files. If this downgrade landed, installations that have already observed epoch 44 would lose rolling compatibility with the new Host/Client pair, and reusing an older number would break the monotonic identity the handshake relies on. Please rebase onto current `main`, read its epoch then, and assign this change a strictly greater value with the corresponding floor test/comment. Do not preselect a fixed number before rebase.
</details>
<details>
<summary>中文</summary>
[P1] 请先 rebase，并保证 compatibility epoch 相对当前 `main` 单调递增。
当前 exact head 用 epoch 43 表示 onboarding 输入新增必填 `connectionId`/`baseUrl` 和新的闭合 rejection 变体，但当前 `main` 已经是 epoch 44。这些 shape 确实不兼容：旧的 exact-record decoder 会拒绝新增必填字段和闭合 union 值，因此不能用 compatible-change 声明豁免。
merge-result guard 在检查具体文件之前，就会把 base=44/head=43 判定为 `went backward`。如果这个降级落地，已经见过 epoch 44 的安装将无法与新的 Host/Client 组合进行滚动兼容；复用更小号码也会破坏握手依赖的单调身份。请先 rebase 到当前 `main`，读取当时的 epoch，再为本变更分配严格更大的值，并同步更新 floor test/comment。不要在 rebase 前预先认领固定号码。
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "UncertaintyDeterminesYou4ndMe (via GitHub)" <gi...@apache.org>.
UncertaintyDeterminesYou4ndMe commented on PR #3467:
URL: https://github.com/apache/maka/pull/3467#issuecomment-5386033850
Rebased again onto current `main` (`efddab2fb`) — `main` moved fast enough that the previous rebase went stale within hours. New head: `327ed2edf`, conflict-free.
Two things changed underneath:
1. **The compatibility epoch advanced to 41** on `main` (40 = queue entry mutations, 41 = compaction terminal outcome), so this PR's onboarding epoch moves again: **both onboarding shapes now land as epoch 42** (same single-epoch reasoning as before — neither was ever published outside this PR's review cycle).
2. **#3571 merged**, fixing #3566 (crash recovery now clears an obsolete onboarding intent instead of bricking the store). It composes cleanly with this PR — and the interaction is worth stating: #3571 detects the obsolete intent by the exact `Onboarding intent conflicts with the connection id` error, which this PR's identity-first upsert leaves reachable only in the replay-after-drift case (a journaled id that no longer exists while the canonical slug is held by a different identity) — exactly the case #3571 now clears. A live intent whose connection still exists is found by id first and replays onto its own slug, never hitting that error. The message text is preserved verbatim since it is now a detection contract.
Local verification on the new head: storage 901 pass / 0 fail (includes #3571's new recovery test alongside this PR's journal tests), CLI 405/405, runtime-host onboarding + protocol suites 65/65, biome clean on the full diff, ASF header audit clean. Ready for the CI approval on this head.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on code in PR #3467:
URL: https://github.com/apache/maka/pull/3467#discussion_r3835651422
##########
packages/cli/src/runtime-host-onboarding.ts:
##########
@@ -35,7 +36,8 @@ export function createRuntimeHostOnboardingSurface(
try {
const result = await connection.request('connection.onboarding.save', {
providerType: input.providerType,
- apiKey: normalizedSecret(input.apiKey),
+ apiKey: trimmedOrNull(input.apiKey),
+ baseUrl: trimmedOrNull(input.baseUrl),
Review Comment:
[P2] The new relay URL is saved by provider type, but `projectProviders()` recognizes an existing connection only at the derived canonical slug. A relay created in Desktop with a valid custom slug is therefore shown as unconfigured in `/setup`; saving here creates a second canonical-slug connection instead of editing/reusing the existing one, leaving the old credential and default target behind. Could onboarding carry the actual existing `connectionId`/slug (or preserve the sole connection for this provider type) through verify/save, with a Desktop custom-slug → TUI re-onboard test? That keeps connection identity authoritative instead of deriving a second one.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "UncertaintyDeterminesYou4ndMe (via GitHub)" <gi...@apache.org>.
UncertaintyDeterminesYou4ndMe commented on PR #3467:
URL: https://github.com/apache/maka/pull/3467#issuecomment-5378438539
## Adversarial review record (pre-submission)
An independent review pass probed the change with running experiments (driven wizard sessions against the built TUI, storage-level probes through the real document stack, protocol decode drills, dist fault injections). It found **five defects, all fixed in the submitted head**, plus confirmations:
### Defects found and fixed
1. **Compatibility epoch not bumped (blocker).** `baseUrl` is required on two closed request shapes and the result unions gained a rejection reason. It demonstrated both mixed-pair directions dying: the frame decode throws inside the session pump and tears the whole Host session down on the first `/setup`. Fixed: `RUNTIME_HOST_COMPATIBILITY_EPOCH = 37`, pinned by a protocol test alongside the existing epoch ladder.
2. **`cloudflare-workers-ai` leaked into the wizard.** Four providers have an empty registry baseUrl, not three — Cloudflare's endpoint is an account-id template that Desktop deliberately keeps out of its base-URL field. Verified by driving the real wizard: it landed on a relay prompt it cannot use. Fixed: the catalog lists empty-baseUrl providers only when `category === 'custom'`; verified the offered set is now exactly the three relays.
3. **A swapped endpoint kept endpoint-keyed state.** Re-onboarding relay-a → relay-b retained `relayModelProfiles` and a "verified" `lastTest` — state the `applyConnectionUpdate` path explicitly drops on endpoint change (its comment: the old table must not outlive the relay it described). Demonstrated side by side through the real storage stack. Fixed: `prepareOnboardingUpsert` derives `endpointChanged` and feeds it into both the profile branch and the test-basis reset; pinned by an end-to-end coordinator test.
4. **Local URL validation omitted the 2048-byte cap**, so an oversized endpoint sailed past the wizard and hit the host's frame decode (fatal per defect 1). Fixed in the wizard's validator.
5. **Two formatter misses** the author's earlier check pipeline had swallowed. Fixed.
It also flagged the storage half as untested — two dist fault injections (removing the URL-change commit condition; making the intent field required) survived every existing suite. The submitted head adds a storage intent-journal test (round-trip + legacy replay) and the endpoint-swap coordinator assertions to close the reachable half of that gap.
### Confirmed safe (with evidence)
- Blank-reuse and crash-recovery replay: a blank save preserves the persisted URL; a hand-written legacy journal (no `baseUrl` key) replays and applies its model change without touching the URL.
- URL replacement probes the new endpoint while reusing the stored secret, and persists at the next revision.
- Normalizer boundary: empty/whitespace → null; query/fragment/credentials/ftp/file/javascript/non-string/oversize all rejected; provider-default collapses to null; decode idempotent; the OAuth-override throw is unreachable (OAuth providers never pass `providerAuthSupportsApiKey`).
- Wizard state machine: 2/4→3/4→4/4 labels; Esc walks exactly one level (models→key→baseUrl→search); a re-entered URL is what reaches verify and save; errors clear on typing; a late verify result after Esc is dropped; a non-relay picked after abandoning a relay carries no leaked URL.
- Rejection ordering: a blank key wins over a missing endpoint, and no discovery probe is issued on any rejection.
- Bypassing the coordinator guard cannot poison the catalog (an endpoint-less relay entry is unusable but loadable).
- Intent `schemaVersion` staying at 1 is correct: strict-equality versioning would break the crash-then-upgrade replay this change is designed to support, while a downgrade already fails closed on the unknown field.
Two observations left as-is, for the record: the protocol accepts an endpoint override for any api-key provider (Desktop's settings already allow the same, and the TUI only offers the step for relays); `hasConnection` is slug-derived, so a Desktop-created relay under a custom slug reads as new in the wizard — pre-existing design, noted since relays are now listed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "UncertaintyDeterminesYou4ndMe (via GitHub)" <gi...@apache.org>.
UncertaintyDeterminesYou4ndMe commented on code in PR #3467:
URL: https://github.com/apache/maka/pull/3467#discussion_r3837872707
##########
packages/cli/src/runtime-host-onboarding.ts:
##########
@@ -35,7 +36,8 @@ export function createRuntimeHostOnboardingSurface(
try {
const result = await connection.request('connection.onboarding.save', {
providerType: input.providerType,
- apiKey: normalizedSecret(input.apiKey),
+ apiKey: trimmedOrNull(input.apiKey),
+ baseUrl: trimmedOrNull(input.baseUrl),
Review Comment:
Implemented in de626752e — connection identity is now authoritative end to end:
- `projectProviders()` resolves the existing connection as the canonical-slug match first, else the provider type's **sole** connection whatever its slug (with several non-canonical connections there is no honest single answer, so the wizard offers a fresh canonical setup); the entry carries its `connectionId`.
- The wizard threads that identity through `verify`/`save` (`connectionId: string | null` on the wire, exact-record like `apiKey`), the coordinator targets it directly — a stale id is rejected as the new `connection_not_found` instead of silently duplicating — and `prepareOnboardingUpsert` finds the row by identity first, preserving its slug. Old credential and default target stay attached because it is the same connection.
- Tests: the Desktop-custom-slug → TUI re-onboard case you asked for (blank re-verify reuses the stored secret **and** the custom-slug endpoint; save with a new URL keeps the id and `my-relay` slug with exactly one connection in the catalog; a stale id rejects), plus projection unit tests (sole-of-type resolves, multiple non-canonical → none, canonical wins) and protocol negatives.
- One consequence caught in pre-push adversarial review: epoch 37 was minted earlier on this same PR for the `baseUrl` shape, and builds of that head exist from this review cycle — so the identity field takes **epoch 38** rather than reusing 37 for a second mutually-undecodable frame.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "UncertaintyDeterminesYou4ndMe (via GitHub)" <gi...@apache.org>.
UncertaintyDeterminesYou4ndMe commented on code in PR #3467:
URL: https://github.com/apache/maka/pull/3467#discussion_r3841061964
##########
packages/runtime-host/src/server/connection-effect-coordinator.ts:
##########
@@ -212,35 +215,48 @@ export class HostConnectionEffectCoordinator {
if (!providerAuthSupportsApiKey(input.providerType)) {
return { kind: 'rejected', reason: 'provider_unsupported' };
}
- const slug = deriveConnectionSlug(input.providerType);
- const catalog = await this.#stores.connectionCatalog.getSnapshot();
- const candidate = catalog.connections.find((connection) => connection.slug === slug);
- if (candidate && candidate.providerType !== input.providerType) {
+ // The begin/complete ticket pair binds this discovery to the connection
+ // revision, credential, and proxy it observed: a concurrent policy update
+ // between the remote probe and the commit supersedes the save instead of
+ // pairing the new endpoint with an inventory it never produced. Verify
+ // simply abandons its ticket (they are WeakMap-held one-shots).
+ const begun = await this.#stores.operations.beginConnectionOnboarding({
+ providerType: input.providerType,
+ connectionId: input.connectionId,
+ });
+ if (begun.kind === 'target_missing') {
+ // Identity supplied by the client names a connection that is gone or
+ // changed provider type: reject instead of deriving a duplicate.
+ return { kind: 'rejected', reason: 'connection_not_found' };
+ }
+ if (begun.kind === 'slug_conflict') {
return { kind: 'rejected', reason: 'slug_conflict' };
}
+ const candidate = begun.connection ?? undefined;
const supplied = input.apiKey?.trim() ?? '';
- const stored = candidate
- ? await this.#stores.operations.exportCredentialMaterial({
- scope: 'connection',
- connectionId: candidate.connectionId,
- kind: 'api_key',
- })
- : null;
- const secret = supplied || stored?.secret || '';
+ const secret = supplied || begun.storedSecret || '';
if (PROVIDER_DEFAULTS[input.providerType].authKind === 'api_key' && secret.length === 0) {
return { kind: 'rejected', reason: 'credential_not_configured' };
}
- const proxy = await this.#stores.operations.resolveNetworkProxyExecution();
- if (proxy.kind !== 'ready') return { kind: 'failed', errorClass: 'network' };
+ // Mirrors the blank-key contract above: a null baseUrl reuses the
+ // existing connection's persisted endpoint or the registry default.
+ // A relay provider with no endpoint from any of those sources cannot
+ // run discovery — reject up front instead of probing an empty URL.
+ const base = candidate
+ ? { ...candidate, ...(input.baseUrl ? { baseUrl: input.baseUrl } : {}) }
+ : transientConnection(input.providerType, input.baseUrl);
+ if (!base.baseUrl && !PROVIDER_DEFAULTS[input.providerType].baseUrl) {
+ return { kind: 'rejected', reason: 'base_url_not_configured' };
+ }
+ // The ticket's basis certifies this exact proxy, so discovery must use
+ // the pinned value rather than re-resolving it (a flip-and-restore
+ // between the two reads would otherwise slip past the basis check).
+ if (begun.proxyCredentialMissing) return { kind: 'failed', errorClass: 'network' };
const transport = this.#createTransport(
- toRuntimePolicyProxy(proxy.networkProxy, proxy.secretMaterial.networkProxy?.secret),
+ toRuntimePolicyProxy(begun.networkProxy, begun.proxySecret ?? undefined),
);
try {
- const effect = await this.#runModelDiscovery(
- candidate ?? transientConnection(input.providerType),
- secret,
- { fetch: transport.fetch },
- );
+ const effect = await this.#runModelDiscovery(base, secret, { fetch: transport.fetch });
Review Comment:
Addressed on head `bc3d1e1d3`.
- `#discoverOnboarding` now probes through `createRequestCustomizationFetch`, exactly as `#withTransport` does: `beginConnectionOnboarding` pins the target's `request_headers` secret alongside the API key (one vault read), and the host applies it plus `base.requestBodyOverlay` — which also covers the baseUrl-override case, since `base` spreads the pinned catalog entry.
- The header credential's status joins the ticket's basis, so a rotation (including absent→present) between discovery and commit supersedes the save like an endpoint or key change would. The body overlay needs no separate pin — it is a catalog property covered by the pinned revision.
- The suggested test is in: a header-authenticated connection with a body overlay asserts the probe carries both (verify and save runs), and that rotating the header credential mid-save supersedes — with the catalog revision asserted unchanged, so the supersede provably comes from the new basis field.
Two scope notes, stated rather than hidden: this restores **re-onboarding** parity — a first-time relay that can only authenticate via a custom header still has no wizard field for one, same as before this PR. And an endpoint override sends the stored header credential to the newly typed host, mirroring the existing stored-API-key semantics of editing a connection in place.
One pre-existing gap surfaced while verifying parity: `modelFetchSemanticBasis` itself omits `requestBodyOverlayJson` (only the connection-test basis carries it), so an overlay edit between `beginModelFetch` and `completeModelFetch` does not supersede even though the probe applied it. Out of scope here — happy to file it as a follow-up.
Verification on this head: storage 908/0, runtime-host 1124/0 (new test included), biome clean.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on PR #3467:
URL: https://github.com/apache/maka/pull/3467#issuecomment-5391982640
LGTM — merging. The wizard being able to create a custom relay connection closes a real gap; thanks for working through the review rounds on it.
<details>
<summary>中文</summary>
看过了，合并。向导能建自定义中转连接补上了一个实际缺口，感谢配合几轮修改。
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "UncertaintyDeterminesYou4ndMe (via GitHub)" <gi...@apache.org>.
UncertaintyDeterminesYou4ndMe commented on code in PR #3467:
URL: https://github.com/apache/maka/pull/3467#discussion_r3840350153
##########
packages/runtime-host/src/server/connection-effect-coordinator.ts:
##########
@@ -196,8 +198,8 @@ export class HostConnectionEffectCoordinator {
#saveOnboarding(
input: ConnectionOnboardingSaveInput,
): Promise<OperationOutcome<'connection.onboarding.save'>> {
- const slug = deriveConnectionSlug(input.providerType);
- return this.#admit(slug, 'connection.onboarding.save', async () => {
+ const lane = input.connectionId ?? deriveConnectionSlug(input.providerType);
+ return this.#admit(lane, 'connection.onboarding.save', async () => {
const prepared = await this.#discoverOnboarding(input);
Review Comment:
Implemented in bbe7af770, following the model-fetch ticket shape you prescribed:
- `beginConnectionOnboarding` (storage, under the write lane) locates the target and issues a one-shot ticket whose basis pins the **connection revision** (covers the endpoint and every catalog-visible property), the **api-key credential status + stored secret from a single vault read**, and the **effective proxy with its credential** — and returns the pinned proxy so discovery runs through the exact egress the basis certifies (re-resolving it later would let a flip-and-restore slip past the check).
- `completeConnectionOnboarding` claims the ticket and revalidates the basis atomically before the durable intent is written: any drift returns `superseded` (new save rejection reason, riding this PR's unpublished epoch), a vanished target still reports `connection_not_found`, and a superseded save writes no journal. Verify abandons its WeakMap-held ticket; save begins its own. The direct `commitConnectionOnboarding` entry point is gone, so there is no unvalidated path left.
- Regression test drives your exact reproduction end to end: discovery paused after observing relay A/key A → concurrent supported catalog update to relay B + key rotation → save returns `rejected: superseded`, relay B/key B intact, relay A's inventory never persisted — then a retry commits cleanly through relay B/key B.
Pre-push adversarial verification (production coordinators, real stores) additionally confirmed: key-rotation-only (no revision bump) supersedes via the credential branch; credential deletion supersedes; first-create vs concurrent canonical-slug create supersedes without double-creating; two racing Host coordinators yield exactly one `saved` and one `superseded` with a single whole inventory; a replayed/forged ticket maps to a sane `invalid_request`, never a session teardown.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(cli): let the TUI wizard create custom relay connections [maka]
Posted by "UncertaintyDeterminesYou4ndMe (via GitHub)" <gi...@apache.org>.
UncertaintyDeterminesYou4ndMe commented on code in PR #3467:
URL: https://github.com/apache/maka/pull/3467#discussion_r3840350902
##########
packages/runtime-host/src/protocol/index.ts:
##########
@@ -91,7 +91,10 @@ export const RUNTIME_HOST_REGISTRATION_SCHEMA_VERSION = 1 as const;
export const RUNTIME_HOST_PROTOCOL_VERSION = 0 as const;
// Increment when the same protocol version no longer guarantees safe Client-Host
// interoperability. Mismatches are rejected before domain commands are admitted.
-export const RUNTIME_HOST_COMPATIBILITY_EPOCH = 42 as const;
+export const RUNTIME_HOST_COMPATIBILITY_EPOCH = 43 as const;
Review Comment:
Done in the rebased head: rebased onto current `main` first, read its epoch then (44), and assigned **45** to this change, with the floor test updated to `> 44` and the comment ladder preserving main's 43/44 entries. No number was preselected before the rebase — and noted for the record: during this rebase git auto-merged the epoch *constant* line once (both sides happened to read the same number) and only conflicted on comments, so the monotonicity check was done explicitly against main's value rather than trusting conflict markers.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org