Skip to content

[onechat] ensure built-in tools have a valid id#227835

Merged
pgayvallet merged 4 commits intoelastic:mainfrom
pgayvallet:onechat-xxx-builtin-tool-ids
Jul 16, 2025
Merged

[onechat] ensure built-in tools have a valid id#227835
pgayvallet merged 4 commits intoelastic:mainfrom
pgayvallet:onechat-xxx-builtin-tool-ids

Conversation

@pgayvallet
Copy link
Copy Markdown
Contributor

@pgayvallet pgayvallet commented Jul 14, 2025

Summary

Follow-up of #227452

Enforce builtin tools follow the expected convention for ids (starting with .)

@pgayvallet
Copy link
Copy Markdown
Contributor Author

/ci

@pgayvallet pgayvallet added release_note:skip Skip the PR/issue when compiling release notes backport:skip This PR does not require backporting v9.2.0 labels Jul 15, 2025
@pgayvallet
Copy link
Copy Markdown
Contributor Author

/ci

Comment on lines +18 to +30
export type BuiltinToolId = `.${string}`;

/**
* Onechat tool, as registered by built-in tool providers.
*/
export interface BuiltinToolDefinition<
RunInput extends ZodObject<any> = ZodObject<any>,
RunOutput = unknown
> extends Omit<ToolDefinition, 'type' | 'configuration'> {
> extends Omit<ToolDefinition, 'id' | 'type' | 'configuration'> {
/**
* Built-in tool ID following the {@link BuiltinToolId} pattern
*/
id: BuiltinToolId;
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Some TS magic to add TS type validation in addition to runtime validation

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

shouldn't type property be always set as builtin type? is tagged union appropriate here?

(if builtin is enum not type not sure it will work)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

There's no type property on BuiltinToolDefinition, we add it automatically in the internals when we convert it to tool definition (we have a few different hybrid types for tool registration)

@pgayvallet pgayvallet marked this pull request as ready for review July 15, 2025 15:04
@pgayvallet pgayvallet requested a review from a team as a code owner July 15, 2025 15:04
};

export const sanitizeToolId = (toolId: string): string => {
return toolId.replace(/[^a-zA-Z0-9_-]/g, '');
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

observation: I think this is the 3rd place in onechat plugin where we define a very similar regex (here as exclusion but still the same), we already have sth like that for tools and agents

Comment on lines +18 to +30
export type BuiltinToolId = `.${string}`;

/**
* Onechat tool, as registered by built-in tool providers.
*/
export interface BuiltinToolDefinition<
RunInput extends ZodObject<any> = ZodObject<any>,
RunOutput = unknown
> extends Omit<ToolDefinition, 'type' | 'configuration'> {
> extends Omit<ToolDefinition, 'id' | 'type' | 'configuration'> {
/**
* Built-in tool ID following the {@link BuiltinToolId} pattern
*/
id: BuiltinToolId;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

shouldn't type property be always set as builtin type? is tagged union appropriate here?

(if builtin is enum not type not sure it will work)

import { createBadRequestError, isReservedToolId } from '@kbn/onechat-common';

const idRegexp = /^[a-z0-9](?:[a-z0-9_-]*[a-z0-9])?$/;
const builtinToolIdRegexp = /^[.][a-z0-9](?:[a-z0-9_-]*[a-z0-9])?$/;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

some regex duplication, but as const so should be fine

Copy link
Copy Markdown
Contributor

@jedrazb jedrazb Jul 16, 2025

Choose a reason for hiding this comment

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

I already forgot why we can't have id start an end with _ or -. I copied the idRegexp from somewhere

i tested in ES rn, and it seems that we are fine creating ids starting with those chars. So perhaps this regex can be simplified to good old a-zA-Z0-9_-

@pgayvallet pgayvallet merged commit 02647f4 into elastic:main Jul 16, 2025
12 checks passed
@elasticmachine
Copy link
Copy Markdown
Contributor

💚 Build Succeeded

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/onechat-common 145 136 -9
Unknown metric groups

API count

id before after diff
@kbn/onechat-common 220 210 -10
@kbn/onechat-server 120 121 +1
total -9

History

Bluefinger pushed a commit to Bluefinger/kibana that referenced this pull request Jul 22, 2025
## Summary

Follow-up of elastic#227452

Enforce `builtin` tools follow the expected convention for ids (starting
with `.`)

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
kertal pushed a commit to kertal/kibana that referenced this pull request Jul 25, 2025
## Summary

Follow-up of elastic#227452

Enforce `builtin` tools follow the expected convention for ids (starting
with `.`)

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport:skip This PR does not require backporting release_note:skip Skip the PR/issue when compiling release notes v9.2.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants