[docs] Plan durable managed-resource reconciliation - #5278
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Closing — superseded by the cluster A session-rebuild stack (#5486 and related). |
Context
PR #5277 deliberately keeps Daytona Secret ownership inside the runner process. That solves plaintext credential delivery without changing the API, but a hard runner crash can leave external Secrets behind.
The original PR #5242 addressed durability with a Daytona-specific lease API and migration. Before shipping that control-plane surface, we need agreement on whether the same primitives should reconcile other external resources such as Composio trigger subscriptions and future MCP authorization relationships.
Changes
This stacked PR adds a design workspace only. It proposes a reusable
managed_resourcesdomain with product-owned intent, desired and observed state, idempotent reservation, optimistic versions, generation-fenced worker claims, bounded retries, and typed provider controllers.The documents cover:
No API code, migration, worker, runner behavior, or deployment configuration is included. Implementation stays paused until the domain, workload-auth, ownership, and fencing decisions are approved.
Review focus
managed_resourcesthe right reusable boundary, or should durability remain controller-specific?Tests / notes
feat/daytona-secret-materialization, the head of PR [feat] Deliver agent credentials through Daytona Secrets #5277.docs/design/agent-workflows/projects/managed-resource-reconciliation/.