fix: allow extension loops to call owned tools - #503
Conversation
|
@franciscpd is attempting to deploy a commit to the Compozy Team on Vercel. A member of the Team first needs to authorize it. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. WalkthroughThe change preserves extension provenance on Loop resources, resolved definitions, and execution snapshots. Daemon execution passes the trusted extension owner to policy resolution. Policy resolution grants only the matching extension source. Tool schemas load once and remain cached. Extension installation persistence uses managed write transactions. ChangesExtension-owned Loop tools
Registry persistence retry
Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: ⚪ Minimal · up to Extension-contributed loops can now call tools owned by the same extension while foreign extension tools remain denied; no actionable merge-blocking risk remains after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant LoopResource
participant ResolveLoop
participant ExecuteActionRun
participant ToolPolicyResolver
participant loopToolSchemaSource
LoopResource->>ResolveLoop: provide extension provenance
ResolveLoop->>ExecuteActionRun: return resolved definition
ExecuteActionRun->>ToolPolicyResolver: attach trusted extension owner
ToolPolicyResolver->>loopToolSchemaSource: load or read cached tool schema
loopToolSchemaSource-->>ToolPolicyResolver: return schema
ToolPolicyResolver-->>ExecuteActionRun: authorize same-owner tool
Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Full details: Linked Issues checkExplanation The changes preserve extension ownership through resource loading, compilation, snapshots, and hydration. Daemon policy grants only the exact same-owner extension source. Tests cover registry projection, context propagation, cancellation, same-owner authorization, foreign tools, forged ownership, and snapshot round-tripping. The provided evidence supports the requirements in issue Full details: Out of Scope Changes checkExplanation Most changes support issue ✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 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 |
|
| Filename | Overview |
|---|---|
| internal/extension/manager_resource_loading.go | Carries canonical extension ownership into loaded Loop resources. |
| internal/loop/executed_definition_snapshot.go | Persists Loop extension provenance in the executed definition snapshot. |
| internal/loop/executed_definition_hydrate.go | Restores persisted extension provenance when hydrating a run. |
| internal/daemon/tool_policy_resolver.go | Adds the exact trusted-context owner to allowed sources without granting trusted-source status. |
| internal/daemon/loop_tool_schema_source.go | Replaces repeated schema lookups with one immutable operator registry projection per compiler source. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart LR
E[Extension manifest owner] --> R[Loop resource]
R --> C[Compiled definition]
C --> S[Executed snapshot]
S --> H[Hydrated run]
H --> P[Daemon policy resolver]
P --> O[Allow exact owner source]
P --> F[Deny foreign extension sources]
O --> T[Resolve same-owner tool]
Reviews (9): Last reviewed commit: "fix: retry extension lifecycle writes" | Re-trigger Greptile
Preserve trusted extension ownership through Loop snapshots and grant only the exact same-owner extension source during daemon execution. Refs compozy#501
eff54a1 to
15f6671
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
| bug_ids: | ||
| fix_status: | ||
| retest_status: | ||
| fix_commits: |
There was a problem hiding this comment.
When a reviewer or later QA run inspects this passed scenario from another checkout, the absolute /home/francisross/dev/qa-labs/... path cannot be opened or restored, so the result and teardown artifacts do not provide durable verification of the recorded verdict.
Context Used: CLAUDE.md (source)
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
What & why
Code-backed extensions can contribute both Loops and tools, but the default external-source policy prevented a contributed Loop from resolving tools owned by that same extension.
This change preserves the canonical manifest owner through resource loading, compilation, executed snapshots, and hydration. During daemon execution it adds only the exact same-owner extension source to the normal allow set; it never grants trusted-source status, and foreign extension sources remain denied. Loop schema compilation also snapshots the operator registry once per compilation instead of repeatedly projecting it.
Closes #501
Codex co-wrote the implementation. I independently reviewed the result and verified it locally.
How you verified it
Impact
No CLI, HTTP/UDS, config.toml, database migration, or web UI contract changes. The change is limited to daemon-side Loop provenance and tool-policy resolution. Public Loop extension documentation and QA coverage are updated.
Summary by CodeRabbit
New Features
Bug Fixes