Skip to content
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

[Obs AI Assistant] Fix null pointer in function definition #203344

Merged
merged 2 commits into from
Dec 9, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@ export const useJsonEditorModel = ({

const initialJsonString = initialJsonValue
? JSON.stringify(safeJsonParse(initialJsonValue), null, 4) // prettify the json
: functionDefinition.parameters.properties
: functionDefinition.parameters?.properties
? JSON.stringify(createInitializedObject(functionDefinition.parameters), null, 4)
: '';

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@

import type { FunctionDefinition } from '@kbn/observability-ai-assistant-plugin/common';

type Params = FunctionDefinition['parameters'];
type Params = NonNullable<FunctionDefinition['parameters']>;

export function createInitializedObject(parameters: Params) {
const emptyObject: Record<string, string | any> = {};
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,9 @@ export type FunctionResponse =
}
| Observable<ChatCompletionChunkEvent | MessageAddEvent>;

export interface FunctionDefinition<TParameters extends CompatibleJSONSchema = any> {
export interface FunctionDefinition<
TParameters extends CompatibleJSONSchema = CompatibleJSONSchema
> {
name: string;
description: string;
visibility?: FunctionVisibility;
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
* 2.0.
*/

import { isChatCompletionChunkEvent, isOutputEvent } from '@kbn/inference-common';
import { ToolDefinition, isChatCompletionChunkEvent, isOutputEvent } from '@kbn/inference-common';
import { correctCommonEsqlMistakes } from '@kbn/inference-plugin/common';
import { naturalLanguageToEsql } from '@kbn/inference-plugin/server';
import {
Expand Down Expand Up @@ -132,9 +132,10 @@ export function registerQueryFunction({
),
logger: resources.logger,
tools: Object.fromEntries(
actions
.concat(esqlFunctions)
.map((fn) => [fn.name, { description: fn.description, schema: fn.parameters }])
[...actions, ...esqlFunctions].map((fn) => [
fn.name,
{ description: fn.description, schema: fn.parameters } as ToolDefinition,
Copy link
Member Author

Choose a reason for hiding this comment

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

@pgayvallet @arturoliduena actions.parameters is typed as ToolSchema whereas esqlFunctions is typed as CompatibleJSONSchema. This gives some incompatibilities when merging the types so I had to do type assertion.

Is the plan to get rid of CompatibleJSONSchema in favor of ToolSchema?

Copy link
Member Author

Choose a reason for hiding this comment

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

CompatibleJSONSchema is defined here

Copy link
Contributor

Choose a reason for hiding this comment

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

Is the plan to get rid of CompatibleJSONSchema in favor of ToolSchema?

I think that question is on your side? CompatibleJSONSchema is a o11y assistant type, ToolSchema is an inference plugin's type. You're more than welcome, and encouraged, to drop your own types in favor of the inference framework's, but that's not really my call, is it?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, in that case it's mostly a question for @arturoliduena

Copy link
Contributor

Choose a reason for hiding this comment

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

I’m also in favor of moving towards using the inference plugin’s types when possible,as it supports a more consistent approach across plugins. However, I had a similar conversation with @dgieselaar and at the moment we agree on keeping o11y assistant types:

#199286 (comment)

Ideally we encapsulate the event type from the inference client here, and convert it into ChatCompletionChunkEvent. We should eventually completely drop ChatCompletionChunkEvent in favor of the inference plugin's types, but that means that we need to make changes in many places, and there's some stuff that isn't supported yet by the Inference plugin's types. Until that happens, I think we should limit the blast radius and stick to our own types where we can - which should be everywhere except for the implementation of this function, I think.

])
),
functionCalling: useSimulatedFunctionCalling ? 'simulated' : 'native',
});
Expand Down
Loading