feat: Add update_orchestrator function to allow users to rotate their… - #34
Conversation
… registered orchestrator - Implements update_orchestrator(env, user, new_orchestrator, name) function - Requires user authentication via user.require_auth() - Loads existing UserAccount and validates orchestrator is registered - Removes old OrchestratorOwner reverse-lookup entry from persistent storage - Sets new orchestrator address and updates reverse lookup - Emits UpdateOrchEvent with user, old_orchestrator, and new_orchestrator - Guards: panics if active_tasks_count > 0 (same as withdraw) - Guards: panics if no orchestrator is currently registered - Adds comprehensive tests covering: - Successful orchestrator rotation - Blocked when task is active - Blocked when no orchestrator registered - Uses #[contractevent] macro for UpdateOrchEvent Fixes clevercon-protocol#8
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds a new Soroban ChangesOrchestrator Update Event
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@contracts/agent-vault/src/lib.rs`:
- Around line 294-302: The account lookup in the user-orchestrator flow is
panicking too early with the "No account" expectation, which prevents first-time
users from reaching the intended no-orchestrator guidance. Update the logic
around the account retrieval in this path so a missing persisted UserAccount is
handled by the same guard flow as an unset orchestrator, and keep the "No
orchestrator registered. Use register_orchestrator instead." behavior reachable
through the existing user/orchestrator handling in this function.
- Around line 321-324: The reverse-lookup update in the orchestrator rotation
flow is overwriting an existing mapping without validation, which can let a
caller take over an address already associated with another owner. Update the
rotation logic around the DataKey::OrchestratorOwner write to first read the
current stored owner for the new orchestrator and only proceed if it is unset or
already belongs to the same user, otherwise reject the change. Use the existing
rotation path in this lib.rs section to keep orchestrator-to-owner resolution
consistent for authorization checks.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: c787e8e1-431d-4c7c-845f-8815dd448a8e
📒 Files selected for processing (2)
contracts/agent-vault/src/lib.rscontracts/agent-vault/src/tests.rs
… registered orchestrator
Fixes #8
Summary
What does this PR do, and why?
Related issue
Closes #
Changes
Testing
How did you verify this works? Include commands run and their output where
useful (e.g.
cargo test,npm test, manual testnet transaction links).Checklist
npm run lintpassesnpm run typecheckpassesnpm testpassesnpm run format:checkpassescargo fmt --check,cargo clippy,cargo testpass in
contracts/<contract>closes #8
Summary by CodeRabbit