Skip to content

Conversation

@zedkipp
Copy link
Contributor

@zedkipp zedkipp commented Dec 16, 2025

Add the API changes to support the feature that transmits boundary logs from workspaces to coderd via the agent API for eventual re-emission to stderr. The API handlers are stubs for now because I'm trying to land this feature from multiple smaller PRs.

High level architecture:

  • Boundary records resource access in batches and sends proto message to agent
  • Agent proxies messages to coderd (captured by the API changes in this PR)
  • coderd re-emits logs to stderr

RFC: https://www.notion.so/coderhq/Agent-Boundary-Logs-2afd579be59280f29629fc9823ac41ba

@zedkipp zedkipp changed the title feat: add inital API for boundary log forwarding to coderd feat: add initial API for boundary log forwarding to coderd Dec 16, 2025
@zedkipp zedkipp marked this pull request as ready for review December 16, 2025 21:12
rpc CreateSubAgent(CreateSubAgentRequest) returns (CreateSubAgentResponse);
rpc DeleteSubAgent(DeleteSubAgentRequest) returns (DeleteSubAgentResponse);
rpc ListSubAgents(ListSubAgentsRequest) returns (ListSubAgentsResponse);
rpc ReportBoundaryLogs(ReportBoundaryLogsRequest) returns (ReportBoundaryLogsResponse);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any opinions on this RPC name?

go.mod Outdated
// by boundary, which lives in a separate repository.
require github.com/coder/coder/v2/agent/proto/boundary_logs v0.0.0-incompatible

replace github.com/coder/coder/v2/agent/proto/boundary_logs => ./agent/proto/boundary_logs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why this is needed and the comment is not really helping.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was a essentially the way to use a nested Go module in a way that doesn't need to refer to a specific version of said module. I was planning to import the nested module in boundary.

I nuked this approach in favor of keeping AgentAPI independent, and separately defining the boundary <-> agent API (future PRs). I realized there’s little benefit from tightly coupling everything now other than re-using generated types. cc @johnstcn

Copy link
Member

@johnstcn johnstcn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Proto changes look OK to me but I'm less certain about having them in the coder/coder repo. What would you think about inverting the direction of the import?

@zedkipp zedkipp force-pushed the zedkipp/boundary-logs-api branch from effad7c to 92de60c Compare December 17, 2025 22:23
Add the API changes to support the feature that transmits boundary logs
from workspaces to coderd via the agent API, then re-emits them to stderr.

Architecture:
- Boundary process connects to Unix socket
- Boundary batches logs and sends TLV prefixed protobuf messages to Agent
- Agent proxies messages to coderd via DRPC
- coderd re-emits to stderr
@zedkipp zedkipp force-pushed the zedkipp/boundary-logs-api branch from 92de60c to 9635d1c Compare December 17, 2025 22:50
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.

3 participants