fix(builder): provision() respects autoProvision + per-call override#86
Merged
Merged
Conversation
…ll override Previously `PathwaysBuilder.provision()` unconditionally called `registerPathwayInstance()`, ignoring the builder's `autoProvision` config. In production with the default `pathwayMode: "managed"` this attempted to upsert a managed pathway and crashed with `managedConfig.endpointUrl is required when provisioning a managed pathway` even when callers had set `autoProvision.pathway: false`. `provision()` now mirrors the `startPump()` semantics: - only provisions data-core / flow-types / event-types when their flag is on - only upserts the pathway instance when `autoProvision.pathway` is true - accepts an optional per-call autoProvision override Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Unrelated to the provision() fix in this PR but blocking it — dnt was resolving the existing `^0.19.0` constraint to 0.19.1, which trips a date-fns type-declaration error during the npm typecheck step. Bumping to ^0.21.2 (the current latest) gets us past it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jbiskur
force-pushed
the
fix/provision-respects-autoprovision-pathway
branch
from
ab8b29f to
84b0521
Compare
date-fns 4.2.0 (released after our last green CI on 2026-05-05) dropped the top-level `types` field from package.json. dnt 0.41.3's bundled TypeScript 5.x can't resolve type defs through the exports map, so the npm build typecheck errors with `Could not find a declaration file for module 'date-fns'` for any transitive importer (e.g. @flowcore/data-pump). Pin to 4.1.0 — the last version with the top-level `types` field — until dnt is updated or date-fns restores the field. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Deno 2.6.1 / TS 5.9 tightened the inferred type of the `init` parameter in `stub(globalThis, "fetch", …)` callbacks so that the standard `RequestInit.body` property is no longer visible. Explicitly cast to `RequestInit | undefined` to dodge the regression without changing runtime behaviour. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Summary
PathwaysBuilder.provision()previously ignoredautoProvisionand always calledregisterPathwayInstance(), which crashed in prod (pathwayMode: "managed"default) when nomanagedConfig.endpointUrlwas supplied — even withautoProvision.pathway: false.provision()now mirrorsstartPump()semantics: shared-resource provisioning is gated ondataCore/flowType/eventType, and the pathway instance is upserted only whenpathway: true.startPump(options.autoProvision)).Why this matters
usable-chatproduction boot is currently crash-looping because the bootstrap callspathways.provision()and the library tries to upsert a managed pathway despiteautoProvision: { pathway: false }. The managed pathway is managed manually via CP/MCP — the library should never auto-create it. This patch unblocks that deployment.Test plan
tests/pathway-builder-provision.test.ts(5 steps), all passing:endpointUrlneeded)autoProvision: { pathway: true }→ managed upsert firesdefaultAutoProvision: false→ nothing provisioned