Skip to content

fix(accounts): a fixture's solution installation follows the authority core's, so its teams are exposed - #1263

Closed
antoinetoussaint-byte wants to merge 1 commit into
mainfrom
accounts/installation-follows-core
Closed

antoinetoussaint-byte wants to merge 1 commit into
mainfrom
accounts/installation-follows-core

Conversation

@antoinetoussaint-byte

Copy link
Copy Markdown
Contributor

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

  • A fixture's declared solution installation is made twice:
    • in the authority core, which activates it at once (consented and composed; accounts wires no core install step);
    • in accounts' own installations table, where it stays pending until the solution's install step is acknowledged.
  • With no consumer acknowledging the step, accounts' row never left pending. Team exposure needs status = '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.

  • accounts' row never activates on its own here: it follows the core only.
  • The core's journal records the activation (saas.authority.installation_activated), so no second event is written.
  • The install-step projection (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 (ListSolutionEntitlements for 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 own InstallSolution (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 1 for pkg/business, pkg/infra and fixtures, and the conformance harness pass locally. Not verified: a composed run against this branch.

🤖 Generated with Claude Code

…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>
@antoinetoussaint-byte
antoinetoussaint-byte added this pull request to the merge queue Oct 27, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 27, 2026
@antoinetoussaint-byte
antoinetoussaint-byte added this pull request to the merge queue Oct 27, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 27, 2026
@antoinetoussaint-byte
antoinetoussaint-byte added this pull request to the merge queue Oct 27, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 27, 2026
@antoinetoussaint-byte
antoinetoussaint-byte added this pull request to the merge queue Oct 27, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 27, 2026
antoinetoussaint-byte added a commit that referenced this pull request Oct 27, 2026
…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>
@antoinetoussaint-byte

Copy link
Copy Markdown
Contributor Author

Folded into #1265, which is now its carrier: c73294e5 is an ancestor of #1265's head and the merge commit's parents are 43350106 c73294e5.

Closing rather than re-queuing, because this PR could not pass CI on its own at all. Host interface conformance (authority main) runs the shared suite at authority's main, which moved when codefly-dev/authority#42 landed ListHeld, so the gate demanded host.installation.v1.InstallationService.ListHeld from a branch that does not implement it:

solution_principal.go:530: the published contract lacks
  host.installation.v1.InstallationService.ListHeld:
  a member's read of the installations they may use

ListHeld appears 152 times in #1265's diff and zero times in this one. That is why this entry fell out of the merge queue three times — a gate reading another repo's moving main, not a flake.

Its substance was verified on the carrier by name rather than by the merge exiting zero: FollowCoreInstallation in pkg/business/installation_follows_core.go, the status IN ('pending','failed') guarded UPDATE at pkg/infra/postgres_installations.go:1167, the call at convergence in fixtures/installations.go:165, and the harness case's three additions. The four GrantInstallationToTeam: cannot expose installation to team warnings are now gone, which is the independent confirmation that this fix does its job on the carrier. The branch is kept.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant