feat(adr-0006)!: Phase 5 — env resolution converges into the KernelResolver seam#1724
Merged
Merged
Conversation
…solver seam BREAKING CHANGE (ADR-0006 Phase 5, final phase): the framework dispatcher no longer performs ANY multi-tenant environment resolution. The ~150-line `resolveEnvironmentContext` (URL → hostname → x-environment-id → session activeEnv → org default-env → single-env default, all via an environment registry) moved to the cloud distribution's resolver (@objectstack/objectos-runtime kernel-resolver.ts), behind the generic `KernelResolver` seam introduced in Phase 2. Dispatcher now: - contributes parsing hints only: `context.routePath` + unvalidated `context.urlEnvironmentId` (URL conventions stay framework-owned); - delegates env resolution + kernel selection to the host resolver, which SETS context.environmentId/dataDriver (membership enforcement, scope TTL touch and scoped service resolution key off them, unchanged); - serves single-environment hosts from defaultKernel with no env context. Removed from the public API: - HttpDispatcherOptions.kernelManager (+ the 'kernel-manager' service pickup for routing; the SERVICE remains a cloud-side concern), - the dispatcher's envRegistry constructor wiring (positional param kept, ignored, so 3-arg callers compile), - `EnvironmentDriverRegistry` / `KernelManager` type exports + runtime/src/cloud/environment-registry.ts (the last file of the cloud/ dir — directory gone; cloud owns its own copies), - @objectstack/hono createHonoApp envRegistry/kernelManager passthroughs (options kept as deprecated-ignored for source compat). handleData's 428 "environment not resolved" guard now keys off a registered kernel-resolver (was: env-registry service) — same multi-tenant signal, same behavior. The dispatcher's resolution test suite moved with the behavior — ported to cloud packages/objectos-runtime/src/kernel-resolver.test.ts (incl. the URL-param precedence / /cloud-skip / header-fallthrough cases). Validation: full-repo build sweep clean; runtime 368 + cli 240 + rest 100 + hono 67 tests green; cloud repo against this checkout: boot-smoke ALL GREEN, objectos-runtime 85 tests, typecheck clean (objectos / ee / cloud), live file-mode HTTP behavior identical (data 401 via requireAuth after hostname resolution through the cloud resolver). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ADR-0006 Phase 5 — 解析策略全归 cloud (final phase; breaking)
The dispatcher's entire multi-tenant environment resolution (URL → hostname →
x-environment-id→ session activeEnv → org default-env → single-env default, all registry-driven) moves to the cloud distribution's resolver behind theKernelResolverseam from Phase 2 (#1718). The framework dispatcher keeps only its own URL-parsing conventions, contributed as hints (context.routePath, unvalidatedcontext.urlEnvironmentId), and servesdefaultKernelwhen no resolver is registered.Removed (breaking)
HttpDispatcherOptions.kernelManager+ the dispatcher'senv-registrywiring (positional ctor param kept-but-ignored so 3-arg callers compile)EnvironmentDriverRegistry/KernelManagertype exports +runtime/src/cloud/environment-registry.ts→ thecloud/directory is gone from the framework runtimecreateHonoAppenvRegistry/kernelManagerpassthroughs (options deprecated-ignored)Contract (documented on
KernelResolver)Resolver owns env resolution + kernel selection; SETS
context.environmentId/dataDriver; downstream stages (membership enforcement, scope TTL touch, scoped services, the data-plane 428 guard) key off them unchanged. The 428 guard's multi-tenant signal is now "a kernel-resolver is registered" (was: env-registry service).Tests moved with the behavior
The
resolveEnvironmentContextsuite is ported to cloudkernel-resolver.test.ts(URL-param precedence,/cloudskip, header fallthrough + new hostname/platform/default-project/unresolved cases).Validation
Full-repo build sweep clean · runtime 368 + cli 240 + rest 100 + hono 67 green · cloud against this checkout: boot-smoke ALL GREEN, objectos-runtime 85, typecheck clean ×4, live file-mode HTTP identical (hostname→env now through the cloud resolver).
Pairs with the cloud PR (resolver impl +
.framework-shabump) — landing immediately after.🤖 Generated with Claude Code