Skip to content

Conversation

antoniibelyshev
Copy link
Collaborator

@antoniibelyshev antoniibelyshev commented Jul 18, 2025

Thank you for opening a pull request! Please add a brief description of the proposed change here.

Also, please tick the appropriate points in the checklist below.


KG-188

Allow to provide condition description and feedback in the retry component.

Type of the change

  • New feature
  • Bug fix
  • Documentation fix
  • Tests improvement

Checklist for all pull requests

  • The pull request has a description of the proposed change
  • I read the Contributing Guidelines before opening the pull request
  • The pull request uses develop as the base branch
  • Tests for the changes have been added
  • All new and existing tests passed
Additional steps for pull requests adding a new feature
  • An issue describing the proposed change exists
  • The pull request includes a link to the issue
  • The change was discussed and approved in the issue
  • Docs have been added / updated

Copy link

github-actions bot commented Jul 18, 2025

Qodana for JVM

381 new problems were found

Inspection name Severity Problems
Check Kotlin and Java source code coverage 🔶 Warning 376
Vulnerable imported dependency 🔶 Warning 4
String concatenation that can be converted to string template ◽️ Notice 1
@@ Code coverage @@
+ 67% total lines covered
8732 lines analyzed, 5932 lines covered
# Calculated according to the filters of your coverage tool

☁️ View the detailed Qodana report

Contact Qodana team

Contact us at [email protected]

*/
public sealed interface ConditionResult {
/**
* Indicates whether the current instance of `ConditionResult` represents a successful state.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: When mentioning symbols, please use square brackets instead of backticks: [ConditionResult]. This would create a proper reference when rendering docs, making it slightly easier to navigate.

@@ -34,26 +94,61 @@ public data class RetrySubgraphResult<Output>(
* @param name The optional name of the subgraph.
* @param defineAction A lambda defining the action subgraph to perform within the retry subgraph.
*/
@Deprecated("Use `condition: suspend AIAgentContextBase.(Output) -> ConditionResult` instead")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's remove instead of deprecating it. It's fine since we are not stable yet.

@@ -124,6 +237,42 @@ public inline fun <reified Input : Any, reified Output> AIAgentSubgraphBuilderBa
* @param strict If true, an exception is thrown if the condition is not met after the maximum retries.
* @param name An optional name for the subgraph.
* @param defineAction A lambda defining the actions within the subgraph.
*/
@Deprecated("Use `condition: suspend AIAgentContextBase.(Output) -> ConditionResult` instead")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here as well, let's remove

*
* @property feedback A descriptive message or information explaining the reason for the rejection.
*/
public class RejectWithFeedback(public val feedback: String): ConditionResult
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we need two separate Reject classes. Can we simply add nullable feedback field to the Reject class with default null value?

// Add clarification messages to the prompt
val clarificationMessages = storage.getValue(clarificationMessagesKey)
llm.writeSession {
updatePrompt {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So on each iteration we are adding all existing clarification messages again? I wonder if this would be an optimal approach, I feel like we would waste tokens this way. How about reworking this approach a bit? We store only the latest clarification message in the storage (not list) and append only it if it's present. All previous messages would be already present in the prompt anyway. And to implement this properly, after every iteration calrificationMessageKey in the storage has to be explicitly cleared if there's no actual clarification message after this iteration, to avoid setting message from the previous iteration twice.

@antoniibelyshev antoniibelyshev force-pushed the belyshev/retry-component-with-feedback branch from 0bf3fc3 to 58b449d Compare August 5, 2025 10:20
@antoniibelyshev antoniibelyshev force-pushed the belyshev/retry-component-with-feedback branch from f5d39df to 46f09b9 Compare August 5, 2025 10:48
Copy link
Collaborator

@tiginamaria tiginamaria left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!
After discussion in dm about condition as a tool and forking/not forking the context, decided that presented approach works fine!

@antoniibelyshev antoniibelyshev dismissed EugeneTheDev’s stale review August 5, 2025 12:55

I addressed the requested changes. If you have other suggestions regarding the retry component, we can discuss them, and I will make updates if needed.

@antoniibelyshev antoniibelyshev merged commit be5a9b2 into develop Aug 5, 2025
6 checks passed
@antoniibelyshev antoniibelyshev deleted the belyshev/retry-component-with-feedback branch August 5, 2025 12:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants