Configure exit policy of AgentValidationManager using a property - #1801
Conversation
|
@deleSerna please confirm this PR is for Embabel 1.5.0 release vs 1.0.1 |
igordayen
left a comment
There was a problem hiding this comment.
@deleSerna - thank you for your contribution, left few comments. Also: how does this check correlate with generic Agent validation method. thanks
igordayen
left a comment
There was a problem hiding this comment.
@deleSerna - could you please consider aligning with:
src/main/kotlin/com/embabel/agent/spi/validation
thanks
@azanux - FYI
|
@deleSerna - build failed; expected failure? |
|
@igordayen Could you clarify what do you meant by this? Move the check to |
https://github.com/embabel/embabel-agent/wiki/Working-with-Multiple-Releases |
I will check. Since both tests around the same criteria, may be VoidAchievesGoalJavaTest need an update . I will check it tomorrow. |
@igordayen In my case, should I just need to target to 1.0.x and would whoever merging the PR will take care of committing that to 1.5.0 and main? |
@deleSerna it us actually developer responsibility to commit to both branches, if required. 1.5.0 - is actually "main" branch, thanks |
Yes, ideally validation to be aligned with existing package structure and good reason why it can not be incorporated into agent structure validation. Thank you. |
Understood, why it's failed. I have wrongly interpreted that only plan type with |
We don't fail on them at the moment. On the other hand, IMO, there is no point in a validation failure that would not result in actual failure as people simply won't notice such warnings. I can create a separate ticket for this and then decide in which branch that should go. |
|
@deleSerna, may I suggest creating an AchievableGoalValidator in a package with existing Agent Validators and employing it? |
igordayen
left a comment
There was a problem hiding this comment.
@deleSerna - more comments added. more leaning to configurable policy. complex conditions require proper documentation, i would suggest.
PR is having conflicts too.
Thank you
|
For multi-agent deployment, single-agent failure should not block server bootstrapping, my thinking |
But there are other validation errors already for which already fail. eg: here . Do you think this violation is different from those ones? |
==> Could you please document the behavior in English, in your own words? Thanks. Related to goals dup too, looping @tuannx |
Therefore, IMO, we could also return null and fail here as this validation error is similar to the cases I mentioned above. |
Please compile full documentation on known agent validators behavior for consistency. Thanks |
|
@deleSerna - please see conflicts. And- what is more important - per analysis, deployments should not be rejected. Thanks |
Looking for consistency to use spring API cross the board. Spring APIs are more resilient than standard JDK |
yes, thanks |
How can AnnotationUtils.findAnnotation be same as isMethodFromSupertype ()? @igordayen I am really not confident about this suggestion from Claude. Therefore, if it's OK I don't apply this suggestions from Claude. Rest all suggestions are applied , including the replacement of |
|
DCO |
|
@deleSerna The current isMethodFromSupertype plus its caller condition is: agentClass.declaredMethods.contains(method) || isMethodFromSupertype(method, agentClass) Both halves together mean: "is this method anywhere in the class hierarchy?" That's exactly what ReflectionUtils.findMethod does in one call: // replaces the entire combined condition ReflectionUtils.findMethod walks declared methods → superclasses → interfaces, handles bridge methods, and is null-safe. The manual traversal in isMethodFromSupertype also has a gap: So the full replacement for isActionMethod: fun isActionMethod( And isConditionMethod: fun isConditionMethod(method: Method, agentClass: Class<*>): Boolean = isMethodFromSupertype, methodSignaturesMatch, and the ClassUtils.getMethodIfAvailable call inside it all disappear. Two helper functions → one Spring call each, with better coverage. |
|
@deleSerna - one more comment (from me, not from Caude:): in number of places: can we have it nicer and have private method: Thanks for consideration |
Signed-off-by: deleSerna <nadeeshtv@gmail.com>
Signed-off-by: deleSerna <nadeeshtv@gmail.com>
f0dd879 to
6a56a49
Compare
Moving that to function still would not simplify it right as I could not do |
@deleSerna You are right; thanks for correcting me (too late:) |
igordayen
left a comment
There was a problem hiding this comment.
@deleSerna - getting closer, thanks. besides unit tests, are you able to test on live agents?
Signed-off-by: deleSerna <nadeeshtv@gmail.com>
|
@deleSerna - did you have a chance to test behavior on live agents? thank you |
igordayen
left a comment
There was a problem hiding this comment.
@deleSerna getting very close!
| const val NO_ACTIONS_TO_GOALS = "NO_ACTIONS_TO_GOALS" | ||
|
|
||
| /** Action annotation is missing on the method. */ | ||
| const val MISSING_ACTION_ANNOTATION = "MISSING_ACTION_ANNOTATION" |
There was a problem hiding this comment.
makes sense to document it?
There was a problem hiding this comment.
Could you please clarify which documentation is missing? MISSING_ACTION_ANNOTATION is already documented.
Signed-off-by: deleSerna <nadeeshtv@gmail.com>
Verifying it. Will update here. |
Signed-off-by: deleSerna <nadeeshtv@gmail.com>
Yes, tested on agent with the following method for both cases - Case - Default (embabel.agent.api.validation.manager.skip-agent-deployment-on-error=false) Case embabel.agent.api.validation.manager.skip-agent-deployment-on-error=true |
There was a problem hiding this comment.
@deleSerna - long journey:) all good now, thank you for contributing!
|
@deleSerna - sorry to disturb. i discovered that log gets severely polluted: Could you please address this ASAP, thank you looping @alexheifetz |
Do you already have a proposal to fix that as it does not looks like duplicate but happening for multiple components? |
|
@deleSerna im currently offline, on mobile. Can't check right now, sorry. |
|
@deleSerna - please execute any Ollama test: embabel-agent/embabel-agent-autoconfigure/models/embabel-agent-ollama-autoconfigure/src/test/java/com/embabel/agent/config/models/ollama/LLMOllamaThinkingIT.java Could you please address this as soon as possible, as we are delaying the release 1.5.2. The BeanPostProcessor calls createAgentMetadata() on every Spring bean. The WARN at line 151 fires for all of them, including Spring Boot's own infrastructure. The fix: downgrade to DEBUG for non-agentic beans. It's expected and normal for a BeanPostProcessor to encounter non-Embabel beans; that's not a warning situation. Proposed change in AgentMetadataReader.kt line 151: // BEFORE // AFTER or remove it at all. Looping in @alexheifetz @tuannx @arnabnandy7 for awareness of the impact of minor changes in logging on developer experience. Thanks |
|
@igordayen Addressing it in PR #2016 |
Issue - #1796
Context - Currently, we are not consistently handling whenever an Agent is failing to adhere to a valid structure ( annotated properly, parameters and return type as expected etc..). In some cases, we are skipping such agent and in some cases, we are just logging a message.
Solution