fix: let an instance name itself - #74
Merged
Merged
Conversation
Identity lets a caller set its own nickname with plain organization membership, and set anyone else's only with can_manage_members. Instances are created from a thread, so forwarding the caller presents an ordinary participant who has neither -- and the Orchestrator reaches this over the mesh with no caller at all, which failed before the call was even made. The instance holds an organization membership tuple by this point: addAgentInstanceAuthorization runs before the nickname is set. So it is the one caller that is always allowed, and it names itself. This lived as a patch the E2E workflow applied to this file at build time, which is how it stayed invisible here.
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.
identity.SetNicknameauthorizes on who the caller is:memberon the organization is enoughcan_manage_membersorcan_add_membersetAgentInstanceNicknameforwarded the caller's identity. Instances are created from a thread, so that caller is an ordinary participant with neither of those permissions — and the Orchestrator reaches instance creation over the mesh with no caller at all, failing inidentityOutgoingContextbefore the call was even made.The instance itself already holds an organization membership tuple at this point (
addAgentInstanceAuthorizationruns before the nickname is set, andregisterAgentInstanceIdentitybefore that), so it is the one caller that is always allowed. It now names itself — the same shape as apps#28.Why no test caught it: this fix has existed only as a patch the E2E workflow applied to
instances.goat build time. The workflow now fails outright —agents instances.go import block not found— because the anchor moved when"strings"was added to the imports. Two tests pin the behaviour instead; both fail onmain.Removing that patch from the E2E workflow is a follow-up in agynio/e2e.