Repository navigation
fix(accounts): a fixture's solution installation follows the authority core's, so its teams are exposed - #1263
antoinetoussaint-byte wants to merge 1 commit into
Conversation
…y core's, so its teams are exposed
A fixture's declared solution installation is made twice: in the authority
core, which activates it at once (consented and composed), and in accounts'
own installations table, where it stays pending until the solution's install
step is acknowledged. With no consumer acknowledging it, every pass failed to
expose its teams ("installation … is not an active installation in this
organization", pkg/infra/postgres_installations.go:1054, which needs status
'active'), so a member reaching the solution through a team held no role.
accounts' record now follows the core's: once fixture convergence finds the
core's installation active, accounts' record of the same installation,
pending or failed at its step, becomes active with the root scope node it
was installed with (ActivateInstallationFollowingCore), and its declared
teams are exposed in the same pass. The core's journal records the
activation. The install-step projection only ever moves a pending row, so a
later acknowledgement changes nothing.
The conformance harness delivers a fixture-declared solution to the running
host: accounts' record is active, the declared team is exposed to it, and a
member of that team is issued a capability through the solution. It fails
without the change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…core's #1263 cannot pass CI alone and never could. Its own gate, "Host interface conformance (authority main)", runs the shared suite at authority's main, which moved when ListHeld landed as the installation interface's additive 0.3.0 → 0.4.0 change, so the suite asks every host for InstallationService.ListHeld and fails the member-navigation case on a contract #1263 does not carry — "the published contract lacks host.installation.v1.InstallationService.ListHeld". This branch is where ListHeld is served, so it is the carrier that makes #1263's change pass. Merged rather than rebased, so its commit keeps its identity (c73294e). No conflicts. What it brings, verified by name rather than by the merge exiting zero: - business.FollowCoreInstallation and the store's ActivateInstallationFollowingCore, which move accounts' own record of a solution installation from pending or failed to active once the core's is active, keeping its root scope node; - the call at fixture convergence (fixtures/installations.go), in the same pass that exposes the declared teams; - the harness case's three additions: accounts' record is active with no install step acknowledged, the declared team is exposed (ListSolutionEntitlements), and a member of that team is issued a capability through the solution. This is also what removes the four "GrantInstallationToTeam: cannot expose installation to team" warnings the conformance fixture printed on this branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Folded into #1265, which is now its carrier: Closing rather than re-queuing, because this PR could not pass CI on its own at all.
Its substance was verified on the carrier by name rather than by the merge exiting zero: |
What we are doing
On a composed run against saas
aaf998b8, the fixture installs the wiki at Acme and the authority core's installation of it is active. Even so, every pass failed to expose its teams:GrantInstallationToTeam: cannot expose installation to team: installation … is not an active installation in this organization, about 118 times per run. A member reaching the wiki through his team held no role there.Root cause
installationstable, where it stayspendinguntil the solution's install step is acknowledged.pending. Team exposure needsstatus = 'active'(pkg/infra/postgres_installations.go:1054,InstallationRootScopePath), so it failed on every pass.The fix
accounts' record now follows the core's. When fixture convergence finds the core's installation active, accounts' record of the same installation (pending, or failed at its step) becomes active. It keeps the root scope node it was installed with (
ActivateInstallationFollowingCore,pkg/business/installation_follows_core.go). The declared teams are then exposed in the same pass.saas.authority.installation_activated), so no second event is written.record_installation_step) only ever moves a pending row, so a later acknowledgement changes nothing.Tests
The conformance harness case "a solution delivered to a running host is installed where the fixture declares it" now also checks three things: accounts' record of the installation is active with no install step acknowledged; the declared Finance team is exposed to it (
ListSolutionEntitlementsfor a Finance member); and that member is issued a capability through the solution. It fails without the change.Fix or hack
A fix, at fixture convergence, where both records of the same installation are made. Reused: the core's install and role grants, accounts' exposure path (
ExposeHostInstallation), and the install-step projection's rule that only a pending row moves. Not done: an installation made through the product's ownInstallSolution(not a fixture) is not installed in the core by this change.Evidence
go vet(both tag sets),go test -tags=pure ./...,go test -race -count=1 -p 1forpkg/business,pkg/infraandfixtures, and the conformance harness pass locally. Not verified: a composed run against this branch.🤖 Generated with Claude Code