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
[TSVB] Replaces hardcoded ids with uuid #97423
Conversation
@timroes @wylieconlon can you think of any reason that we can't replace these hardcoded ids? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this was the only place in TSVB where we weren't using uuid? It seems safe in theory, I haven't run the code.
@@ -25,11 +25,11 @@ export const metricsVisDefinition = { | |||
group: VisGroups.PROMOTED, | |||
visConfig: { | |||
defaults: { | |||
id: '61ca57f0-469d-11e7-af02-69e470af7417', | |||
id: uuid.v1(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have chosen to use import uuid from 'uuid/v4'
in Lens because it's fully random: uuid v1 is not a random ID.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes Wylie, only here we are using hardcoded ids. Everywhere else we are using uuid.v1()
Nice feedback about v4, will use this instead 🙂
Pinging @elastic/kibana-app (Team:KibanaApp) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR makes the problem much less severe, but it's still possible to end up with identical ids because uuid.v4()
is only called once on Kibana client start. This means if a user creates multiple TSVB visualizations without reloading the page, they will end up with the same ids again.
If they reload the page, it will work as expected.
Leaving it up to you whether that's good enough.
Thanx Joe, no it is not, I will change the implementation. thanx for that 🙂 |
@@ -15,7 +15,6 @@ import { EditorController, TSVB_EDITOR_NAME } from './application/editor_control | |||
import { createMetricsFn } from './metrics_fn'; | |||
import { metricsVisDefinition } from './metrics_type'; | |||
import { | |||
setSavedObjectsClient, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Irrelevant with this PR but we dont use anywhere this setter/getter
@@ -17,10 +17,6 @@ export const [getFieldFormats, setFieldFormats] = createGetterSetter< | |||
DataPublicPluginStart['fieldFormats'] | |||
>('FieldFormats'); | |||
|
|||
export const [getSavedObjectsClient, setSavedObjectsClient] = createGetterSetter<SavedObjectsStart>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
@elasticmachine merge upstream |
@flash1293 it should be ok now! |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested this PR the follwing way:
- Create new dashboard
- Add TSVB panel - save without changing anything
- Add second TSVB panel - save again without changing anything
- Hitting refresh
It would expect the requests sent by the panels to be different, but all ids are identical.
@flash1293 yes, I know about this case but it seems to be a very edge case. It happens because you don't change anything on the editor, so it initializes with the same id. |
@stratoula Hm, I did the following now:
In the request to TSVB, the panel ids are different, but series ids and metric ids are still identical. In the issue linked above it seems like these are the ones this is all about:
I also checked the request sent to ES from TSVB and it does not include the panel id, but series and metric id. panel 1:
panel 2:
requests:
As a quick fix we might be able to add the panel id to the |
Thank you Joe! I will try to add the panel id to meta. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested the previous case and unique panelId
is added to the request. This should be enough to cross-correlate with the problematic visualization by searching on the kibana index. LGTM
@flash1293 thank you a lot for your help with this issue ❤️ |
💛 Build succeeded, but was flaky
Test FailuresKibana Pipeline / general / Chrome UI Functional Tests.test/functional/apps/visualize/input_control_vis/chained_controls·ts.visualize app input controls chained controls should filter child control options by parent control valueStandard Out
Stack Trace
Metrics [docs]Async chunks
Page load bundle
Unknown metric groupsReferences to deprecated APIs
History
To update your PR or re-run it, just comment with: |
* [TSVB] Replace hardcoded ids with uuid * Use v4 instead * Add id on the model initialization * Change the id in case of new visualization * Add paneld to the meta object Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [TSVB] Replace hardcoded ids with uuid * Use v4 instead * Add id on the model initialization * Change the id in case of new visualization * Add paneld to the meta object Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
Closes #96670.
It removes the hardcoded ids from TSVB and replaces them with uuid.
I have made some tests and I can't find any regression or any reason that we can't do it.
Example of a TSVB SO: