Repository navigation
fix!: build on Core main and host v0.0.103; add accounts.Datasources() - #45
Merged
Merged
Conversation
Core 22ddde98 removed the approved build from a Work Context: SealSource lost ApprovedBuild and ErrNoApprovedBuild is gone, so verifier_sources.go no longer compiled for any consumer whose build selects Core main. The floor moves to b81d92e6feda, the Core host v0.0.103's gateway requires; WorkContextSources drops ApprovedBuild rather than keeping a local sentinel. Core v0.19.5 still requires that method, so no single source builds against both. gen/ regenerates from released module-saas-starter v0.0.103 with the pinned buf.gen.yaml toolchain and reproduces byte-for-byte. conformance/hostgateway re-binds to the host's workloadListener (af5cef9a serves the mints on the workload endpoint alone) and realigns the two expectations that commit changed: Unauthenticated on the work-context mint is 401, and that mint no longer holds the internal token. moduleauthority's fake follows. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
accounts.Client.Datasources() wraps the generated DatasourceServiceClient beside Audit(): ListSources, GetSource, AddSource, ListSourceOperations, DeclareSourceOperations, InvokeSourceOperation, LookupInvokeSourceOperation and the three account-link RPCs, bare messages in and out. Every message, enum, enum value and oneof wrapper they reach is re-exported from accounts. It reads responses through the same client as package datasource, moved to internal/connectresponse, and documents datasource's Invoke/Lookup as the effect-safe path. internal/apiboundary now walks a oneof field's exported wrappers instead of reporting its unaliasable interface. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
AntoineToussaint
force-pushed
the
fix/core-v0.19.4-floor
branch
from
October 21, 2026 18:37
b7169d3 to
db5a4b3
Compare
antoinetoussaint-byte
marked this pull request as ready for review
October 21, 2026 18:38
host-gateway-conformance installed Go from the SDK's go.mod (1.27.0) under setup-go's GOTOOLCHAIN=local, and host v0.0.103's auth-gateway module requires go 1.27.2, so the build refused before any test ran. The job builds the gateway module with this SDK required into it; it now installs the newer of the two go directives. Co-Authored-By: Claude Opus 5.5 (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
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.
This SDK now builds on Core main
b81d92e6fedaand host v0.0.103.accounts.Clientgains aDatasources()facade besideAudit(), so a consumer connecting and calling a host-owned API source no longer importsgen/. The branch is rebased onto main after #44, and #45's uncachedMintModuleWorkContextis kept.This cannot also build against Core v0.19.5. Core
22ddde98("no build seal in a Work Context") removedApprovedBuildfromSealSourceand deletedErrNoApprovedBuild. v0.19.5 is not its descendant and still requiresSealSource.ApprovedBuild. SoWorkContextSourcescan satisfy one interface or the other, never both: at v0.19.5 the build fails with*WorkContextSources does not implement workcontext.SealSource (missing method ApprovedBuild). The floor is therefore Core's pseudo-versionv0.19.6-0.20261018051341-b81d92e6feda. MVS never selects v0.19.5 beside it. The floor should move to the first Core tag containing22ddde98.Changes, classified (AGENTS.md)
All are fixes at the owner, none is a hack:
b81d92e6feda;WorkContextSources.ApprovedBuildremoved. Core's verifier no longer asks an issuer for a build. That method's only correct "bears no execution" answer was the sentinel Core deleted, so it goes, with no local sentinel.sealed_test.goand the conformance helper stop setting theExecutionCore removed fromStartInput. This is the Core the v0.0.103 gateway itself requires.gen/regenerated from released module-saas-starter v0.0.103 (2cb00737) throughbuf.gen.yaml, buf v1.73.0, protoc-gen-go v1.36.11 and protoc-gen-connect-go v1.20.0. It reproduces byte-for-byte; main's recorded9ab36e7tree also reproduced.SOURCE.txtrecords v0.0.103. Nothing ingen/was hand-edited.conformance/hostgatewayre-bound to v0.0.103. Hostaf5cef9a(starter#1120) serves the three mints on the gateway's workload endpoint only; the public endpoint answers 404. The harness now serves the real gateway through the host's ownworkloadListener, as a native run's workload server does. That is a fifth unexported binding, listed in the file and in the harness's AGENTS.md. Two expectations change, both stated by that host commit: accounts'Unauthenticatedon the work-context mint is now 401 /ErrInvalidCredentials(was 502), and that mint no longer checks the internal token. The two operation mints still do, and the test still asserts that.moduleauthority's fake gateway andTestTheBrokerRefusesAWrongPerimeterCredentialfollow (the latter now exercises the operation mint).Seams.Gateway's doc now names the workload endpoint.accounts.Client.Datasources()covers the 10 listed RPCs, with the same shape asAuditClient. Every message, enum, enum value and oneof wrapper they reach is re-exported inaccounts/types.gounder its generated name, e.g.&accounts.AddSourceRequest{Config: &accounts.AddSourceRequest_Api{…}}andaccounts.ApiOAuth2Config_GRANT_AUTHORIZATION_CODE. That list is complete with pooling across packages switched off, i.e.accountsnames everything itself.host-gateway-conformanceinstalls the newer of the SDK's and the gateway'sgodirective. The job installed Go from the SDK'sgo.mod(1.27.0) under setup-go'sGOTOOLCHAIN=local. Host v0.0.103's gateway requiresgo 1.27.2, so the job refused to build (requires go >= 1.27.2 (running go 1.27.0)). This fixes the tool that owns the step; it is not a workaround in the harness.internal/apiboundarynow reaches oneof wrappers. A oneof field's type is an unexported interface nothing can alias. The gate used to report that interface and stop; now it walks the exported wrappers implementing it and requires each to be re-exported. A newoneoffixture proves this: disabling the change turnsTestGateCatchesKnownBypassesred withisOneofThing_Choice.Reuse, and what was deliberately not built
datasource/already wrapsDatasourceServiceergonomically. ItsInvoke/Lookupmint effect IDs and classifyErrOutcomeUnknown. A second, independent client would be a second mechanism. The two are layered instead:datasource's response-encoding client moves unchanged tointernal/connectresponse, and both facades bind their generated client to it, so a Connect error reads the same through either.Datasources()is documented as the raw contract, anddatasource.Invoke/Lookupas the effect-safe way to call an operation.UpdateSource,SyncSource,DeleteSource, GitHub App setup, domains, delegations, triggers, reconciliation, receipt pruning).c4a25cd), apart from resolving its conflict with feat(moduleauthority): serve core's three live-authority sources to a callee's verifier #44'sErrNoHostStateToMintFor, which it now shares.Breaking changes
(*moduleauthority.WorkContextSources).ApprovedBuildis removed (Core removed the interface method).af5cef9a:ModuleMintWorkContextRequest.Upstream/.Manifestand their getters;SolutionBackendBinding;SolutionRegistration.Backend;SolutionFrontendBinding.ContractVersion;SolutionRegistrationStatus_SOLUTION_REGISTRATION_STATUS_INCOMPATIBLE. No hand-written facade exposed them, andmoduleauthoritynever sentUpstream/Manifest.UpdateSource(DatasourceService) andGetRetainedSolutionFrontend(SolutionRegistryService). This breaks only implementers that don't embedUnimplemented…Handler.Docs changed
README.md,CHANGELOG.md,AGENTS.md,.github/workflows/ci.yml,conformance/hostgateway/AGENTS.md,.claude/skills/api-boundary-triage/SKILL.mdand.claude/skills/refresh-generated-api/SKILL.md.CHANGELOG.mdalso gains av0.1.3heading over the entries that tag already shipped (it was tagged at14fe024without one).go test -count=1 ./internal/apiboundary/: the gate loads code throughgo list, so a cached run reports the tree as it was before an edit.Verified
testdata/) at Coreb81d92e6feda:go build,go vet,go test -count=1,go test -raceandgofmtall clean.conformance/hostgateway/run.sh <host@v0.0.103> -race: 9 tests ran and passed.codefly-dev/solution-runtime-gomain (14afd95), with this tree replacing itsb7169d3pin, resolves Coreb81d92e6fedaand passesgo build,go vetandgo test ./....test,gen-driftandhost-gateway-conformanceall pass.b7169d3, which the force-push un-references, is still served by proxy.golang.org (.infoand.zipboth 200), so solution-runtime-go v0.0.15 keeps resolving.Not verified
authenticatedWorkloadListenerwraps the mints in a cell. The harness uses the native-runworkloadListener.Datasources()against a real host. The tests use an httptest Connect server (procedure, unwrap, Connect error withErrorInfopreserved, one subtest per method) and nothing more.🤖 Generated with Claude Code