[OneChat] Test Tool Flyout#230484
Conversation
064431c to
64b623e
Compare
6e7702c to
35d372e
Compare
jedrazb
left a comment
There was a problem hiding this comment.
works nicely! couple of comments
x-pack/platform/plugins/shared/onechat/common/http_api/tools.ts
Outdated
Show resolved
Hide resolved
x-pack/platform/plugins/shared/onechat/public/application/components/tools/esql/esql_tool.tsx
Show resolved
Hide resolved
| return fields; | ||
| }; | ||
|
|
||
| export const OnechatTestFlyout: React.FC<OnechatTestToolFlyoutProps> = ({ |
There was a problem hiding this comment.
Oh I meant that on small screens (as in my attachment) the input and response columns are squashed (maybe we should have input and response in a single column??)
...k/platform/plugins/shared/onechat/public/application/components/tools/execute/test_tools.tsx
Outdated
Show resolved
Hide resolved
...k/platform/plugins/shared/onechat/public/application/components/tools/execute/test_tools.tsx
Outdated
Show resolved
Hide resolved
x-pack/platform/plugins/shared/onechat/public/application/hooks/tools/use_execute_tools.ts
Outdated
Show resolved
Hide resolved
x-pack/platform/plugins/shared/onechat/public/services/tools/tools_service.ts
Outdated
Show resolved
Hide resolved
987f75e to
19303c3
Compare
| languageId="json" | ||
| value={response} | ||
| fullWidth={true} | ||
| height="calc(100vh - 275px)" |
There was a problem hiding this comment.
This part feels a bit tricky, manually calculating CSS height likely won't cover all cases? Also it probably need to have minimal height?
From what I understand, the code editor requires an explicit height. Why not set it to 100%? Could we instead use flexbox to let it stretch automatically?
Also, since the result is read-only, is there a reason we’re using the CodeEditor component (which is meant for dynamic input)? Wouldn’t a EuiCodeBlock be simpler and more lightweight approach here?
There was a problem hiding this comment.
From what I've seen CodeEditor would make more sense especially as responses could be pretty long and searching through results could get confusing using just a code block. As for the explicit height, I can see why calculating the height could be flaky, and so just set it to "75vh" which would allow to scroll through responses and keep the 'Response' title at the top.
There was a problem hiding this comment.
Hmm, thinking out loud right now:
- The response doesn’t work too well on narrow screens (see screenshot). overflow-x is hidden, so I can’t really see the full response.

- this is especially problematic when rendering tabular data output from tool (horizontal)
- We also have issues with calculating height.
What if we just stacked everything in a column instead?
- Params on top
- Response below params (under the test button)
- This would make better use of the narrow flyout
- We could just use full height of response and just let flyout scroll?
would make more sense especially as responses could be pretty long and searching through results could get confusing using just a code block.
Tools return typed data, so we are likely to have custom renderers anyway for .e.g esql result. You can still use cmnd F to search through JSON right?
I pasted ^ to cursor and it suggested this (stacking in column, using EuiCodeBlock).
Screen.Recording.2025-08-27.at.13.53.37.mov
jedrazb
left a comment
There was a problem hiding this comment.
One more pass, spotted couple more nits :)
...k/platform/plugins/shared/onechat/public/application/components/tools/execute/test_tools.tsx
Outdated
Show resolved
Hide resolved
...k/platform/plugins/shared/onechat/public/application/components/tools/execute/test_tools.tsx
Outdated
Show resolved
Hide resolved
...k/platform/plugins/shared/onechat/public/application/components/tools/execute/test_tools.tsx
Outdated
Show resolved
Hide resolved
...k/platform/plugins/shared/onechat/public/application/components/tools/execute/test_tools.tsx
Outdated
Show resolved
Hide resolved
...k/platform/plugins/shared/onechat/public/application/components/tools/execute/test_tools.tsx
Outdated
Show resolved
Hide resolved
...k/platform/plugins/shared/onechat/public/application/components/tools/execute/test_tools.tsx
Outdated
Show resolved
Hide resolved
| const { errors } = formState; | ||
| const { errors, isDirty } = formState; | ||
| const [showTestFlyout, setShowTestFlyout] = useState(false); | ||
| const [testToolData, setTestToolData] = useState<OnechatEsqlToolFormData>(form.getValues()); |
There was a problem hiding this comment.
Why do we need this state? Can't we infer testToolData directly from const form = useEsqlToolForm();?
There was a problem hiding this comment.
We are always forcing user to save before executing the tool, we could even simplify to pass just toolId to flyout test tool form , and then from within flyout form we can fetch the tool by Id using a hook useTool(toolId)
IMO this will be cleaner and we won't need to handle state propagation to child component
There was a problem hiding this comment.
I ended up using the hook to get the full tool data but did need to use a current tool id state since the flyout can be either from Creating or Editing
jedrazb
left a comment
There was a problem hiding this comment.
few nits! last ones i hope
...k/platform/plugins/shared/onechat/public/application/components/tools/execute/test_tools.tsx
Outdated
Show resolved
Hide resolved
...k/platform/plugins/shared/onechat/public/application/components/tools/execute/test_tools.tsx
Outdated
Show resolved
Hide resolved
x-pack/platform/plugins/shared/onechat/public/application/components/tools/esql/esql_tool.tsx
Outdated
Show resolved
Hide resolved
|
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
Page load bundle
History
|
## Summary This PR adds the ability to test a tool when editing or creating it. It adds a "Save and Test" button that will save the tool before testing or just a "Test" button so if there were no changes to an existing tool, it'll open the flyout that will use the `_execute` API endpoint for testing. <img width="1916" height="867" alt="Screenshot 2025-08-25 at 5 04 52 PM" src="https://github.com/user-attachments/assets/6b45df50-c515-426c-9837-46c1ea9fd2ee" /> <img width="1917" height="860" alt="Screenshot 2025-08-27 at 12 47 19 PM" src="https://github.com/user-attachments/assets/deb309b0-e38d-4bfa-a4b8-587d09e84919" /> ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) - [ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] [See some risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) - [ ] ... --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>



Summary
This PR adds the ability to test a tool when editing or creating it. It adds a "Save and Test" button that will save the tool before testing or just a "Test" button so if there were no changes to an existing tool, it'll open the flyout that will use the
_executeAPI endpoint for testing.Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
release_note:breakinglabel should be applied in these situations.release_note:*label is applied per the guidelinesbackport:*labels.Identify risks
Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging.