feat: respond to OpAMP RequestInstanceUid flag with agent_identification for newly enrolled agents#6834
Open
michel-laterman wants to merge 11 commits intoelastic:mainfrom
Open
Conversation
michel-laterman
added
enhancement
Contributor
|
This pull request does not have a backport label. Could you fix it @michel-laterman? 🙏
|
Contributor
🔍 Preview links for changed docs |
Contributor
✅ Vale Linting ResultsNo issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
michel-laterman
commented
Apr 14, 2026
michel-laterman
force-pushed
the
opamp-request-instance-uid
branch
from
4483de3 to
161b0e4
Compare
When an agent sets the RequestInstanceUid flag in AgentToServer.flags, fleet-server now generates a new UUID v7 and returns it in ServerToAgent.agent_identification.new_instance_uid as required by the OpAMP spec. Closes elastic#6789 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When generating a new instance UID, create a new .fleet-agents document under the new ID (preserving agent metadata) and delete the old document so the agent record carries over rather than forcing a re-enrollment. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…directly Adds TestHandleMessageNewEnrollmentWithRequestInstanceUid which verifies that when an unenrolled agent sets RequestInstanceUid, enrollment uses the new UID as the agent ID and reassignAgentID is not called. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When an enrolled agent requests a new instance UID, reassignAgentID now applies the checkin fields (status, health, capabilities, effective config, timestamps) to the agent document before creating it. This eliminates the separate updateAgent/CheckIn call, reducing the write operations for the reassignment path. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Reassigning an enrolled agent's instance UID is not yet supported; reassignAgentID now returns errors.ErrUnsupported so enrolled agents requesting a new UID get an error response. New enrollments continue to work — the generated UID is used as the agent ID during enrollment. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
michel-laterman
force-pushed
the
opamp-request-instance-uid
branch
from
8e6fdaa to
8b90402
Compare
michel-laterman
changed the title
ycombinator
reviewed
Apr 22, 2026
| }, | ||
| } | ||
| } | ||
| newInstanceUID = &uid |
Contributor
There was a problem hiding this comment.
Could we set instanceUID here to &uid? I think it might simplify some of the code later.
Contributor
Author
There was a problem hiding this comment.
As per the spec, the response's instance_uid value must match the request's even if the request has the new instance_uid flag set
ycombinator
reviewed
Apr 22, 2026
Co-authored-by: Shaunak Kashyap <ycombinator@gmail.com>
michel-laterman
force-pushed
the
opamp-request-instance-uid
branch
from
e0a9cff to
c6d2382
Compare
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
3 participants
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.
What is the problem this PR solves?
Fleet-server ignores the
AgentToServer.flags.RequestInstanceUidflag and does not respond withServerToAgent.agent_identification, which is required by the OpAMP spec.How does this PR solve the problem?
When an agent sets the
RequestInstanceUidflag, fleet-server treats the message as a new enrollment regardless of whether an agent with the incominginstance_uidalready exists:handleMessagechecks the flag early and, when set, skips thefindEnrolledAgentlookup entirely.enrollAgentgenerates a fresh UUID v7 and uses it as the agent's ID; the new agent document is stored in.fleet-agentsunder that UID.AgentIdentification.NewInstanceUidwith the generated UID. The agent is expected to adopt the new UID for subsequent messages per the spec.InstanceUidstill echoes the incominginstance_uidper the spec.If
agent_disconnectis set together withRequestInstanceUid(or for an unenrolled agent), fleet-server returns aBadRequesterror response.Reassigning an already-enrolled agent's instance UID without re-enrollment is intentionally out of scope for this change. Doing so would require decoupling the
.fleet-agentsdocument_idfrominstance_uid, which today are the same value (consistent with the rest of fleet-server).How to test this PR locally
docs/opamp.md).AgentToServermessage withflagsset to1(RequestInstanceUid). The response should includeagent_identification.new_instance_uidwith a valid UUID v7 distinct from the incominginstance_uid, and a new document in.fleet-agentsshould exist under the generated UID.Design Checklist
Checklist
./changelog/fragmentsusing the changelog toolRelated issues
AgentToServer.flags.RequestInstanceUid#6789