Cache buster broken for releases #1363
Labels
bug
Something isn't working
Comments
|
I'm not sure how to adequately raise the awareness on this, but this is a terrible issue that has rendered Dashboards unusable for most of our users. Attempts to downgrade to 1.2.0 were unsuccessful. Any assistance with remediating or addressing this would be appreciated. |
|
Hello @JeffBolle, Thank you for opening this issue! Sorry that you are seeing this issue. Would you be willing share some information on all your index-pattern looks like? Did you successfully migrated from 1.0 to 1.1, and 1.1 to 1.2? Or did you onboard with 1.2? There is an issue with caching: opensearch-project/opensearch-build#1769 that you could be running into. |
|
I'm happy to share whatever is needed. I cleared out my personal .kibana tenant index and have been testing with that. When I clear it out I can load the discover tab, but as soon as I add any index pattern, I can no longer load the discover tab. I believe we started with OpenSearch 1.2. What should I try to mitigate the caching issue? |
|
If you are able to mitigate the caching issue and resolves it please let me know. If it is a caching issue then that's something we dropped the ball on it and I apologize for that, and we should definitely work on prioritizing opensearch-project/opensearch-build#1769 |
|
I just loaded dashboards in an Incognito window and that worked! Thank you, I sincerely appreciate the help late in the day on a Friday. For now its definitely feasible to have our users flush their cache, but that gave us quite the scare! |
|
@JeffBolle, I really apologize for the caching issue and the scare! It was an huge oversight when we were building out our build system, I will ensure that for whatever next release that the cache breaker will be fixed. But thank you for opening this issue it really helps with making the case to prioritize the issue! |
|
@kavilla No worries! Hopefully this issue also helps others that run into it solve it quickly. The 1.3.0 upgrade (to get continuous transforms) was a key step in our process of migrating from ElasticSearch 7.10.2 to OpenSearch. We've now moved our largest data system over and so far it is going very smoothly, all things considered. We appreciate the hard work being done by all of the teams involved. |
|
Thanks for migrating so quickly and thanks for opening this issue. I'm going to retitle it and pin into the repo for visibility. |
kavilla
changed the title
kavilla
added a commit
to kavilla/OpenSearch-Dashboards-1
that referenced
this issue
Mar 23, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. Issues resolved: * opensearch-project/opensearch-build#1769 * opensearch-project#1363 Signed-off-by: Kawika Avilla <[email protected]>
kavilla
added a commit
to kavilla/OpenSearch-Dashboards-1
that referenced
this issue
Mar 23, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. Issues resolved: * opensearch-project/opensearch-build#1769 * opensearch-project#1363 Signed-off-by: Kawika Avilla <[email protected]>
7 tasks
kavilla
added a commit
to kavilla/OpenSearch-Dashboards-1
that referenced
this issue
Mar 23, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * opensearch-project#1363 Signed-off-by: Kawika Avilla <[email protected]>
7 tasks
kavilla
added a commit
that referenced
this issue
Mar 24, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]>
opensearch-trigger-bot bot
pushed a commit
that referenced
this issue
Mar 24, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988)
kavilla
added a commit
that referenced
this issue
Mar 24, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988) Co-authored-by: Kawika Avilla <[email protected]>
opensearch-trigger-bot bot
pushed a commit
that referenced
this issue
Mar 30, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988)
kavilla
added a commit
that referenced
this issue
Mar 31, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988) Co-authored-by: Kawika Avilla <[email protected]>
|
@JeffBolle, we have released |
opensearch-trigger-bot bot
pushed a commit
that referenced
this issue
Apr 14, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988)
opensearch-trigger-bot bot
pushed a commit
that referenced
this issue
Apr 14, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988)
opensearch-trigger-bot bot
pushed a commit
that referenced
this issue
Apr 14, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988)
kavilla
added a commit
that referenced
this issue
Apr 25, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988) Co-authored-by: Kawika Avilla <[email protected]>
kavilla
added a commit
that referenced
this issue
Apr 25, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988) Co-authored-by: Kawika Avilla <[email protected]>
kavilla
added a commit
that referenced
this issue
Apr 25, 2022
When running a release build for example: ``` yarn build-platform --linux --skip-os-packages --release ``` The build task runs through get_build_number and checks how many commits you have locally and determines the build number. From there, and this is the value that is used to as a cache busting mechanism. However, in the release build repo https://github.com/opensearch-project/opensearch-build When this gets packaged and verified it actually pulls from the specified branch and only retrieves the HEAD commit. Thus making the count of commits locally equal to `1` and get_build_number always return `1` for releases essentially breaking the cache buster. The build repo however, sets an env variable of `BUILD_NUMBER` so if this value is available it will use it instead of commit count. The CI runs the unit tests and only gets the latest commit as well so instead of setting a env build number and basically creating the same unit test only check this locally. Issues resolved: * opensearch-project/opensearch-build#1769 * #1363 Signed-off-by: Kawika Avilla <[email protected]> (cherry picked from commit 797d988) Co-authored-by: Kawika Avilla <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Update
Previous title: Dashboards Discover blank after upgrade to 1.3.0
Problem: Release builds are always building OpenSearch Dashboards with a build number equal to 1 which breaks the cache buster
Workaround: Clear cache
Issue: opensearch-project/opensearch-build#1769
Describe the bug
After upgrading to OpenSearch Dashboards 1.3.0, users are unable to use the discover tab, although the Dashboard tab still works.
To Reproduce
Steps to reproduce the behavior:
0. Upgrade from a working 1.2.0 Dashboards installation
Expected behavior
To see the index pattern chooser and search results.
OpenSearch Version
1.3.0
Dashboards Version
1.3.0
Plugins
Standard install.
Screenshots
Here is the error from the browser console:
osd-ui-shared-deps.js:434 TypeError: Cannot read properties of undefined (reading 'kueryQuerySyntax')
at QueryBarTopRow (:5601/1/bundles/plugin/data/data.chunk.4.js:1:137586)
at ua (:5601/1/bundles/osd-ui-shared-deps/osd-ui-shared-deps.js:434:59332)
at Ms (:5601/1/bundles/osd-ui-shared-deps/osd-ui-shared-deps.js:434:104414)
at gl (:5601/1/bundles/osd-ui-shared-deps/osd-ui-shared-deps.js:434:90018)
at fl (:5601/1/bundles/osd-ui-shared-deps/osd-ui-shared-deps.js:434:89943)
at ol (:5601/1/bundles/osd-ui-shared-deps/osd-ui-shared-deps.js:434:87291)
at :5601/1/bundles/osd-ui-shared-deps/osd-ui-shared-deps.js:434:45733
at t.unstable_runWithPriority (:5601/1/bundles/osd-ui-shared-deps/osd-ui-shared-deps.js:442:3462)
at Hi (:5601/1/bundles/osd-ui-shared-deps/osd-ui-shared-deps.js:434:45442)
at Gi (:5601/1/bundles/osd-ui-shared-deps/osd-ui-shared-deps.js:434:45678)
ds @ osd-ui-shared-deps.js:434
Host/Environment (please complete the following information):
Additional context
I've heard from some users that they do not have the problem. However a large number do.
The text was updated successfully, but these errors were encountered: