Sorry for the delay. I suggest that for now we implement agent_disconnect for WebSocket only. If necessary we can add it for http transport later.

I believe this logic should be added to HTTP too in order for the collector to be spec-compliant.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.19%. Comparing base (3521293) to head (28f76f3).
⚠️ Report is 5 commits behind head on main.

@@            Coverage Diff             @@
##             main     #384      +/-   ##
==========================================
+ Coverage   80.10%   80.19%   +0.09%     
==========================================
  Files          27       27              
  Lines        2578     2590      +12     
==========================================
+ Hits         2065     2077      +12     
  Misses        395      395              
  Partials      118      118              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

The build is failing because of a bug that will be fixed by #425
Need to wait for that PR to be merged first.

@minuk-dev please rebase. The build should now pass.

I believe this logic should be added to HTTP too in order for the collector to be spec-compliant.

@agardnerIT I agree with you. But, I think the spec is ambiguous.
But, if we try to send agent_disconnect, we should one more AgentToServer message http.

https://github.com/open-telemetry/opamp-spec/blob/main/specification.md#websocket-transport-opamp-client-initiated

To close a connection the Client MUST first send an AgentToServer message with agent_disconnect field set. The Client MUST then send a WebSocket Close control frame and follow the procedure defined by WebSocket standard.

Should we suggest to add the spec like
"The Client SHOULD send the AgentToServer message with agent_disconnect field set, if the Client is HTTP"?
Honestly, I'm not sure about it. Because sometimes, the http client is hard to send additional message.
So I agree #384 (comment) this review.

Could you please open new issue to discuss it, if you need?
Honestly, this PR is too longly opened... I'm not enough time to do it.