Skip to content

Conversation

@Jonas-Isr
Copy link
Member

@Jonas-Isr Jonas-Isr commented Dec 23, 2025

Context

The PR enables the management of Orchestration Configs in prompt registry (create, delete, list via generated code and new client) as well as convenience to use these Orchestration Configs in the OrchestrationClient.

Sample of new convenience:

// create OrchestrationPrompt (for placeholder values and history) with already existing convenience
List<Message> history = List.of(new SystemMessage("System Message"));
OrchestrationPrompt prompt = new OrchestrationPrompt(Map.of("placeholder", "value")).messageHistory(history);

// create (newly added) OrchestrationConfigReference to refer to saved Orchestration config
OrchestrationConfigReference reference =
    OrchestrationConfigReference.fromScenario("scenario").name("name").version("0.0.1");

// use OrchestrationClient todo chat completion with the referenced config
OrchestrationChatResponse response = client.executeRequestFromReference(prompt, reference);

Feature scope:

  • add new OchestrationConfigClient in prompt registry
    • unit and e2e tests for generated code and new client in prompt registry
  • convenience for use with OrchestrationClient
    • unit and e2e tests for new convenience

Definition of Done

  • Functionality scope stated & covered
  • Tests cover the scope above
  • Error handling created / updated & covered by the tests above
  • Aligned changes with the JavaScript SDK
  • Documentation updated
  • Release notes updated

@Jonas-Isr Jonas-Isr self-assigned this Dec 23, 2025
@Jonas-Isr Jonas-Isr added the please-review Request to review a pull-request label Dec 23, 2025
Comment on lines +15 to +18
@Value
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@Beta
public class OrchestrationConfigReference {
Copy link
Member Author

Choose a reason for hiding this comment

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

I decided against making this a sealed interface plus two permitted classes because I felt that would be a bit of an overkill for such little logic. Would be interested in your thoughts about that.

*
* @since 1.14.0
*/
public class OrchestrationConfigClient extends OrchestrationConfigsApi {
Copy link
Contributor

Choose a reason for hiding this comment

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

(Major/Discussion)

I don't think we want to extend a custom class from generated code. Did we do that before? Is there no other way to apply mixins? Otherwise this has a code smell; we're introducing hand-written public API code for the sake of a workaround.

Copy link
Contributor

Choose a reason for hiding this comment

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

We did that in PromptClient and GroundingClient. It's only to add mix-ins.

*/
@Nonnull
public static Builder fromScenario(@Nonnull final String scenario) {
return new Builder(scenario);
Copy link
Contributor

Choose a reason for hiding this comment

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

(Minor)

You could've turned this into a currying builder, when the classes were interfaces.

return (name) -> (version) -> new OrchestrationConfigReference(null, scenario, name, version);

Copy link
Contributor

@CharlesDuboisSAP CharlesDuboisSAP left a comment

Choose a reason for hiding this comment

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

Looking good 😎

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

please-review Request to review a pull-request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants