-
Notifications
You must be signed in to change notification settings - Fork 42
Add humanContactChannels to Agent Spec (not in-use yet) #56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add humanContactChannels to Agent Spec (not in-use yet) #56
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Looks good to me! Reviewed everything up to 76f6d6f in 2 minutes and 25 seconds
More details
- Looked at
512lines of code in9files - Skipped
1files when reviewing. - Skipped posting
11drafted comments based on config settings.
1. kubechain/api/v1alpha1/agent_types.go:21
- Draft comment:
New field HumanContactChannels is added correctly to AgentSpec. Ensure future documentation reflects its intended usage. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
2. kubechain/internal/controller/agent/agent_controller.go:125
- Draft comment:
New function validateHumanContactChannels follows pattern of other validations. Ensure error messages (e.g. 'failed to get ContactChannel') consistently match testing expectations. - Reason this comment was not posted:
Confidence changes required:30%<= threshold50%
None
3. kubechain/config/crd/bases/kubechain.humanlayer.dev_agents.yaml:52
- Draft comment:
CRD schema update for humanContactChannels and validHumanContactChannels looks correct. Ensure required fields are kept in sync with API changes. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
4. kubechain/internal/controller/agent/agent_controller_test.go:252
- Draft comment:
Test cases for non-existent HumanContactChannel verify error handling; verify that error message substring matches actual output from validateHumanContactChannels. - Reason this comment was not posted:
Confidence changes required:30%<= threshold50%
None
5. kubechain/test/utils/objects_utils.go:43
- Draft comment:
New helper logic for setting up HumanContactChannels in the TestScopedAgent is clear and aligns with the API; no issues found. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
6. kubechain/.gitignore:32
- Draft comment:
MacOS specific system files (.DS_Store) are now ignored. This is standard and looks fine. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
7. kubechain/api/v1alpha1/agent_types.go:21
- Draft comment:
Addition of HumanContactChannels in AgentSpec and ValidHumanContactChannels in AgentStatus looks good. Consider adding further validations (e.g. non-empty type) if future use cases require stricter constraints. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%
None
8. kubechain/config/crd/bases/kubechain.humanlayer.dev_agents.yaml:53
- Draft comment:
CRD schema correctly reflects the new HumanContactChannels and ValidHumanContactChannels fields. Ensure consistency with the API definitions in future versions. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
9. kubechain/internal/controller/agent/agent_controller.go:125
- Draft comment:
The new validateHumanContactChannels function is implemented correctly. Consider explicitly checking for NotFound errors (using errors.Is(err, apierrors.IsNotFound)) to differentiate not found cases from other errors, and note the repeated status-update blocks could be refactored for clarity. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
The comment addresses real patterns in the code - there is error handling that could be more specific, and there are repeated status update blocks. However, the error handling pattern is consistent with the rest of the codebase (validateLLM, validateTools, etc all handle errors the same way). The repeated status blocks are an existing pattern, not introduced by this PR. The PR only adds a new validateHumanContactChannels function following the existing patterns.
The suggestions would improve the code quality. Not distinguishing NotFound errors could make debugging harder. The repeated status blocks do make the code harder to maintain.
While valid suggestions, they address existing patterns in the codebase rather than issues with the changes made in this PR. The new code simply follows the established patterns.
Delete the comment. While the suggestions are valid, they are about existing code patterns rather than issues with the changes made in this PR.
10. kubechain/internal/controller/agent/agent_controller_test.go:252
- Draft comment:
Test cases now cover successful validation and failures for invalid HumanContactChannel references. Consider adding an extra test for the scenario where a ContactChannel exists but isn’t ready. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%
None
11. kubechain/test/utils/objects_utils.go:43
- Draft comment:
TestScopedAgent setup now correctly builds HumanContactChannels references. The approach is consistent with Tools. This looks good. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
Workflow ID: wflow_SfpfRG7PsLFxoyol
You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.
| statusUpdate.Status.Ready = false | ||
| statusUpdate.Status.Status = StatusError | ||
| statusUpdate.Status.StatusDetail = err.Error() | ||
| statusUpdate.Status.ValidTools = validTools |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
weird to me that we set all these things every time we reconcile
| statusUpdate.Status.Status = StatusError | ||
| statusUpdate.Status.StatusDetail = err.Error() | ||
| statusUpdate.Status.ValidTools = validTools | ||
| statusUpdate.Status.ValidMCPServers = validMCPServers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
weird that this falls through here - like why don't we set it where we compute it? Right now, if I'm reading this code, I have to go scroll up and see where validMCPServers came from in order to know what's happening here.
like is this nil in this case? is this computed?
dexhorthy
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approved but we need to clean up that status data stuff soon
Add cool dudes like this:
We'll get to actually putting this to work in the next PR.
Important
Add
humanContactChannelstoAgentSpecandAgentStatus, updating API, controller logic, and tests for future use.HumanContactChannelstoAgentSpecandAgentStatusinagent_types.go.kubechain.humanlayer.dev_agents.yamlto includehumanContactChannels.validateHumanContactChannels()inagent_controller.goto validate contact channels.Reconcile()inagent_controller.goto handlehumanContactChannels.HumanContactChannelsinzz_generated.deepcopy.go.agent_controller_test.goto testhumanContactChannelsvalidation.TestScopedAgentinobjects_utils.goto includeHumanContactChannels.This description was created by
for 76f6d6f. It will automatically update as commits are pushed.