additional_properties reference #1022
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Refactor LLM client auto-configuration structure - Removed `KoogAutoConfiguration` and related legacy configuration files. - Introduced modular `LLM` provider-specific auto-configuration classes (e.g., `OpenAILLMAutoConfiguration`). - Updated test setup to align with the new modular configuration. - Enhanced property validation with `enabled` flag support for finer-grained control. - Introduced a `String.masked` extension to obfuscate sensitive string parts. Added test coverage for various input scenarios, including custom mask characters and edge cases. - Updated `KoogAutoConfigurationTest` to include scenarios where providers are explicitly disabled. - Refactored parameterized tests to use `textBlock = PROVIDERS` with `@CsvSource`. - Adjusted `ApplicationContextRunner` configuration logic for clean test scenarios. - Introduced `ignoreUnknownFields` to all `ConfigurationProperties` to improve flexibility with unmapped fields. - Expanded property documentation for all LLM clients (e.g., OpenAI, Google, Anthropic) to include detailed descriptions, usage examples, and retry behavior. - Improved autowiring safety with `@ConditionalOnBean` for LLM-specific executors. - Updated `spring-boot.md` to detail `enabled` flags and their default behavior for LLM providers. - Improved clarity by reformatting the supported provider list. - Added explanations for default base URLs and explicit activation for non-API-key providers (e.g., Ollama). A blog post about writing Spring Boot starters is [here](https://kpavlov.me/blog/spring-boot-starters) **NB! Tests need a split and some love, but this PR is already big enough. I will refactor them separately.** ## Motivation and Context - The Spring Boot configuration in general is not very Spring Boot idiomatic - The current Spring Boot starter does not expose LLM Clients. In order to get the LLM client in the application, developers have to use reflection to a get a field from the executor 🤯 - All configuration is encapsulated in one file, which makes extensibility difficult (SRP is violated). - Defaults are hardcoded in classes instead of being provided in the resources - Ollama is enabled by the presence of the base URL, which is interesting. - There is no explicit way to disable an LLM provider: no `enabled=true` property ## Breaking Changes - AutoConfiguration classes moved to their respective packages - Ollama provider needs `ai.koog.ollama.enabled=true` to be set explicitly in order to activate. --- #### Type of the changes - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [x] Breaking change (fix or feature that would cause existing functionality to change) - [x] Documentation update - [x] Tests improvement - [x] Refactoring #### Checklist - [x] The pull request has a description of the proposed change - [ ] I read the [Contributing Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md) before opening the pull request - [x] 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 - [x] Docs have been added / updated
Updated documentation on functional agents --- #### Type of the changes - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [x] Documentation update - [ ] Tests improvement - [ ] Refactoring #### Checklist - [ ] The pull request has a description of the proposed change - [ ] I read the [Contributing Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md) 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
…ations (JetBrains#889) <!-- 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. --> ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> As a follow-up to our last week discussion, it's good to test different input/output combinations in tool descriptors after the merge of JetBrains#791. ## Breaking Changes <!-- Will users need to update their code or configurations? --> None. --- #### Type of the changes - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update - [x] Tests improvement - [ ] Refactoring #### Checklist - [x] The pull request has a description of the proposed change - [x] I read the [Contributing Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md) before opening the pull request - [x] The pull request uses **`develop`** as the base branch - [x] Tests for the changes have been added - [x] All new and existing tests passed ##### Additional steps for pull requests adding a new feature - [x] An issue describing the proposed change exists - [x] The pull request includes a link to the issue - [x] The change was discussed and approved in the issue - [ ] Docs have been added / updated
## Motivation and Context Add new strategy `structuredOutputWithToolsStrategy` that combines structured output capabilities with tool execution, enabling agents to generate structured responses while leveraging external tools. This implementation includes: - New `nodeSetStructuredOutput` node for configuring structured output in agent graphs - `parseResponseToStructuredResponse` method in AIAgentLLMSession for parsing structured responses - Support for both sequential and parallel tool execution - Example demonstrating weather forecast generation with tools and structured output The strategy follows a pipeline: set structured output → execute input → call LLM → handle tool calls or transform structured response → return final output. Fixes JetBrains#400 ## Breaking Changes N/A --- #### Type of the changes - [x] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update - [ ] Tests improvement - [ ] Refactoring #### Checklist - [x] The pull request has a description of the proposed change - [x] I read the [Contributing Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md) before opening the pull request - [x] The pull request uses **`develop`** as the base branch - [x] Tests for the changes have been added - [x] All new and existing tests passed ##### Additional steps for pull requests adding a new feature - [x] An issue describing the proposed change exists - [x] The pull request includes a link to the issue - [ ] The change was discussed and approved in the issue - [x] Docs have been added / updated --------- Co-authored-by: Ruben Cagnie <[email protected]>
- Massive updates in the commit 3a315e4 miss several places. Updated all related namings in tests and inspections
- Add LLM Streaming events to be able to use these events with feature processors; - Updated all relevant features, including EventHandler, Tracer, Debugger; - Add or update tests for each feature to verify streaming events handling.
Fix final messages collection in integration test for history compression
<!-- 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. --> ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> Fixed the OOM exception when running the Ollama tests by: - Adding cleanup scripts for docker and runner; - Enhancing Ollama fixture and its extension; - Parallelizing test classes; - Limiting artifact retention duration. Also, fixed some issues with the tests and removed obsolete println-s that I used when manually checked the Ollama execution log. I don't think they belong to the CI pipeline. ❗ Important: I have little experience with Docker and Testcontainers and memory optimization, hence I used Claude to help me with this problem. In case you see something wrong or contre-logical, feel free to point out. ➕ some unrelated fixes added after rebase to develop to make klintcheck pass ## Breaking Changes <!-- Will users need to update their code or configurations? --> None. --- #### Type of the changes - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update - [x] Tests improvement - [x] Refactoring #### Checklist - [x] The pull request has a description of the proposed change - [x] I read the [Contributing Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md) before opening the pull request - [x] The pull request uses **`develop`** as the base branch - [x] Tests for the changes have been added - [x] 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
- replace `CLAUDE.md` with `AGENT.md` - update guideline The goal is to provide a single guideline for any code agents, not just for claude code
…Brains#894) The problem is that `@PropertySource` annotations in auto-configuration classes don't make properties available to `@ConditionalOnProperty` annotations during the auto-configuration phase. This is a known limitation in Spring Boot. The `@PropertySource("classpath:/META-INF/config/koog/*-llm.properties")` in `*LLMAutoConfiguration` doesn't load the properties early enough for the `@ConditionalOnProperty(prefix = *KoogProperties.PREFIX, name = ["enabled"], havingValue = "true")` to see them. - Created `KoogAutoConfigurationIntegrationTest` to verify LLM clients and executors registration. - Added `it-application.properties` with test configuration for LLM providers. - Fixed the issue by moving `@ConditionalOnProperty` to LLM Client bean declaration from the AutoConfiguration classes - Updated JavaDocs to clarify property usage and activation conditions. - Introduced `toRetryingClient` extension function for retryable LLM clients. - Added enhanced tests for default and custom retry configurations. - Updated `RetryConfig` with a new `DEFAULT` configuration constant for standard use cases. - Introduce `ConditionalOnPropertyNotEmpty` annotation and improve LLM provider configuration - Added `@ConditionalOnPropertyNotEmpty` for enhanced property validation in LLM auto-configuration classes, replacing `@ConditionalOnProperty` for required properties. - Refactored `KoogAutoConfigurationTest` to reduce repetition by introducing `createApplicationContextRunner`. - **Updated provider-specific property files to support environment variable injection for API keys directly.** - Improved documentation to clarify configuration using environment variables. - Adjusted integration test configurations for better alignment with provider-specific setups. - Added logging to LLM auto-configuration classes for better visibility during client and executor creation. ## Motivation and Context Spring Boot does not load create Koog beans unless `ai.koog.PROVIDER.enabled` is explicitly defined in the application configuration. I have seen that the auto-configuration was not loaded previously unless `@Import(KoogAutoConfiguration::class)` is explicitly added. After this change, the minimal Spring Boot configuration `application.yml` for OpenAI looks like this: ```yaml # You don't have to specify anything here ``` , given that the environment variable `OPENAI_API_KEY` was set. ## Breaking Changes No --- #### Type of the changes - [ ] New feature (non-breaking change which adds functionality) - [x] Bug fix (non-breaking change which fixes an issue) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update - [x] Tests improvement - [x] Refactoring #### Checklist - [x] The pull request has a description of the proposed change - [x] I read the [Contributing Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md) before opening the pull request - [x] The pull request uses **`develop`** as the base branch - [x] 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 --------- Co-authored-by: Copilot <[email protected]>
…dencies in build.gradle.kts
## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> ## Breaking Changes <!-- Will users need to update their code or configurations? --> --- #### Type of the changes - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update - [ ] Tests improvement - [ ] Refactoring #### Checklist - [ ] The pull request has a description of the proposed change - [ ] I read the [Contributing Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md) 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
A new code-agent example is added.
- Added information about functional agents. - JetBrains is now explicitly mentioned in the framework description. --- ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> ## Breaking Changes <!-- Will users need to update their code or configurations? --> --- #### Type of the changes - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [x] Documentation update - [ ] Tests improvement - [ ] Refactoring #### Checklist - [ ] The pull request has a description of the proposed change - [ ] I read the [Contributing Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md) 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
…d deprecations (JetBrains#910) Rename Persistency to Persistence everywhere, provide replacements and deprecations #### Type of the changes - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update - [ ] Tests improvement - [x] Refactoring #### Checklist - [ ] The pull request has a description of the proposed change - [ ] I read the [Contributing Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md) 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
…encyId` class field (JetBrains#904) <!-- 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. --> ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> ## Breaking Changes <!-- Will users need to update their code or configurations? --> --- #### Type of the changes - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update - [ ] Tests improvement - [x] Refactoring #### Checklist - [ ] The pull request has a description of the proposed change - [ ] I read the [Contributing Guidelines](https://github.com/JetBrains/koog/blob/main/CONTRIBUTING.md) 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 --------- Co-authored-by: Konstantin Pavlov <[email protected]> Co-authored-by: Vadim Briliantov <[email protected]>
Add documentation for A2A support in Koog.
0.5.0 release with change log
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation and Context
There was an open issue that wanted a parameter added called extra_body. someone added a parameter called additional_properties that serves the same intended purpose as extra_body, but the issue is still open. I created a reference to additional_properties called extra_body that aligns with what the open issue was looking for.
Breaking Changes
Will users need to update their code or configurations?
No. Nothing breaks once they add in the reference.
Type of the changes
New feature
Checklist
developas the base branchAdditional steps for pull requests adding a new feature