-
Notifications
You must be signed in to change notification settings - Fork 711
feat: Depricate http api and add multistream search v2 #8735
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
Conversation
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.
Greptile Overview
Summary
This PR implements a comprehensive deprecation of the HTTP API multistream search v2 functionality across the OpenObserve codebase, transitioning to a unified HTTP/2 streaming approach. The changes affect both frontend (TypeScript/Vue) and backend (Rust) components, involving significant architectural refactoring.Backend Changes:
- Adds new streaming endpoints (
search_multi_stream) alongside existing v2 endpoints for backward compatibility - Introduces enhanced multi-stream processing with concurrent query execution and progress consolidation
- Implements bulk permission validation for improved performance
- Adds comprehensive audit logging for enterprise features
- Updates response structures with optional
query_indexfield for better query correlation
Frontend Changes:
- Refactors large monolithic composables into focused, modular utilities (useSearchQuery, useSearchConnection, useSearchResponseHandler, etc.)
- Removes WebSocket-based search functionality entirely, consolidating on HTTP/2 streaming
- Eliminates conditional logic that previously supported multiple communication methods (REST, WebSocket, streaming)
- Updates UI components to remove deprecated configuration toggles
- Simplifies query execution paths by removing partition-based and HTTP-based search methods
Architecture Impact:
The refactoring transforms a complex multi-protocol system into a streamlined HTTP/2 streaming architecture. This reduces code maintenance burden while providing better real-time capabilities for search operations. The extensive modularization of frontend code improves testability and separation of concerns, particularly for the previously 2100+ line useSearchStream composable.
Migration Strategy:
The approach maintains backward compatibility by keeping existing endpoints active while introducing new streaming equivalents, enabling gradual client migration. Configuration flags are hardcoded to force streaming behavior, ensuring consistent execution paths across all environments.
Important Files Changed
Changed Files
| Filename | Score | Overview |
|---|---|---|
| src/config/src/meta/search.rs | 5/5 | Adds optional query_index field to Response struct for query correlation |
| web/src/composables/useLogs/logsUtils.ts | 5/5 | Removes WebSocket trace ID handling, consolidates to HTTP-only |
| web/src/composables/useLogs/useHistogram.ts | 4/5 | Removes getHistogramQueryData function and HTTP-based histogram fetching |
| web/src/utils/zincutils.ts | 4/5 | Hardcodes feature flags: WebSocket disabled, streaming enabled |
| web/src/layouts/MainLayout.vue | 5/5 | Removes deprecated WebSocket/streaming search configuration options |
| web/src/composables/useLogs/useSearchQuery.ts | 4/5 | New modular composable extracting query construction logic |
| web/src/services/streaming_search.ts | 4/5 | Adds searchMulti function for multi-stream search endpoint |
| web/src/composables/useLogs/useSearchResponseHandler.ts | 4/5 | New composable handling WebSocket search responses and streaming data |
| web/src/components/dashboards/VariablesValueSelector.vue | 4/5 | Removes WebSocket variable loading, consolidates to HTTP streaming |
| web/src/composables/useLogs/useSearchHistogramManager.ts | 3/5 | New histogram manager with potential type safety and error handling issues |
| src/handler/http/request/search/multi_streams.rs | 4/5 | Adds new streaming multi-search endpoint with enhanced features |
| web/src/composables/useLogs/useSearchStreamRefactored.ts | 3/5 | New refactored orchestrator composable with potential dependency issues |
| src/service/search/streaming/mod.rs | 4/5 | Implements concurrent multi-query processing with streaming |
| web/src/composables/useLogs/useSearchStream.ts | 2/5 | Major refactoring to orchestrator pattern with missing dependency risks |
| web/src/composables/useLogs/useSearchBar.ts | 4/5 | Removes HTTP search logic, simplifies to streaming-only approach |
| web/src/composables/dashboard/useValuesWebSocket.ts | 4/5 | Refactors to remove WebSocket, consolidates to HTTP streaming |
| web/src/composables/dashboard/usePanelDataLoader.ts | 4/5 | Major refactoring removing WebSocket and partition methods |
| web/src/composables/useStreamingSearch.ts | 4/5 | Adds conditional routing between single/multi-stream endpoints |
| web/src/components/settings/General.vue | 4/5 | Removes deprecated streaming configuration UI toggles |
| web/src/composables/useLogs/useSearchPagination.ts | 4/5 | New pagination utility extracted from main composable |
| web/src/composables/useLogs/useSearchConnection.ts | 3/5 | New connection abstraction with potential initialization issues |
| web/src/composables/useLogs.ts | 4/5 | Removes processHttpHistogramResults function and related imports |
| web/src/test/unit/helpers/handlers.ts | 5/5 | Removes websocket_enabled flag from mock config |
| src/handler/http/router/mod.rs | 4/5 | Adds new search_multi_stream service route |
Confidence score: 3/5
- This PR involves extensive refactoring with potential runtime risks due to missing composable dependencies and incomplete migration paths
- Score reflects concerns about large-scale architectural changes that could introduce breaking changes if dependencies aren't properly established
- Pay close attention to useSearchStream.ts, useSearchStreamRefactored.ts, and useSearchConnection.ts for missing dependency issues
Additional Comments (1)
-
web/src/components/dashboards/VariablesValueSelector.vue, line 628 (link)style: Comment still mentions 'WebSocket Implementation' but this section now only handles HTTP2/streaming. Update comment to reflect current implementation.
24 files reviewed, 23 comments
| import { cloneDeep } from "lodash-es"; | ||
| import { SearchRequestPayload } from "@/ts/interfaces/query"; | ||
| import { | ||
| convertDateToTimestamp, |
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.
style: convertDateToTimestamp is imported but never used in this file
| convertDateToTimestamp, | |
| import { searchState } from "@/composables/useLogs/searchState"; | |
| import { logsUtils } from "@/composables/useLogs/logsUtils"; | |
| import { useStore } from "vuex"; | |
| import { useRouter } from "vue-router"; | |
| import { cloneDeep } from "lodash-es"; | |
| import { SearchRequestPayload } from "@/ts/interfaces/query"; | |
| import { | |
| getConsumableRelativeTime, | |
| } from "@/utils/date"; | |
| import config from "@/aws-exports"; | |
| import { b64EncodeUnicode, addSpacesToOperators } from "@/utils/zincutils"; |
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/src/composables/useLogs/useSearchQuery.ts
Line: 23:23
Comment:
**style:** `convertDateToTimestamp` is imported but never used in this file
```suggestion
import { searchState } from "@/composables/useLogs/searchState";
import { logsUtils } from "@/composables/useLogs/logsUtils";
import { useStore } from "vuex";
import { useRouter } from "vue-router";
import { cloneDeep } from "lodash-es";
import { SearchRequestPayload } from "@/ts/interfaces/query";
import {
getConsumableRelativeTime,
} from "@/utils/date";
import config from "@/aws-exports";
import { b64EncodeUnicode, addSpacesToOperators } from "@/utils/zincutils";
```
How can I resolve this? If you propose a fix, please make it concise.| let node: any; | ||
| let index: any; | ||
| for (field of searchObj.data.stream.selectedStreamFields) { | ||
| for ([node, index] of parsedSQL) { |
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.
logic: Using for...of with destructuring on arrays may not work as expected. The loop iterates over array elements, not index-value pairs
| for ([node, index] of parsedSQL) { | |
| for (let i = 0; i < parsedSQL.length; i++) { | |
| const node = parsedSQL[i]; | |
| if (node === field.name) { | |
| parsedSQL[i] = '"' + node.replaceAll('"', '') + '"'; | |
| } | |
| } |
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/src/composables/useLogs/useSearchQuery.ts
Line: 372:372
Comment:
**logic:** Using `for...of` with destructuring on arrays may not work as expected. The loop iterates over array elements, not index-value pairs
```suggestion
for (let i = 0; i < parsedSQL.length; i++) {
const node = parsedSQL[i];
if (node === field.name) {
parsedSQL[i] = '"' + node.replaceAll('"', '') + '"';
}
}
```
How can I resolve this? If you propose a fix, please make it concise.| streams | ||
| .join(",") | ||
| .split(",") |
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.
logic: Calling .join(',').split(',') is redundant and inefficient - streams is already an array
| streams | |
| .join(",") | |
| .split(",") | |
| streams | |
| .forEach((item: any) => { |
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/src/composables/useLogs/useSearchQuery.ts
Line: 429:431
Comment:
**logic:** Calling `.join(',').split(',')` is redundant and inefficient - `streams` is already an array
```suggestion
streams
.forEach((item: any) => {
```
How can I resolve this? If you propose a fix, please make it concise.| return; | ||
| } | ||
|
|
||
| console.log("Page count", payload, response); |
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.
style: Remove debug console.log statement before merging to production
| console.log("Page count", payload, response); | |
| // console.log("Page count", payload, response); |
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/src/composables/useLogs/useSearchResponseHandler.ts
Line: 145:145
Comment:
**style:** Remove debug console.log statement before merging to production
```suggestion
// console.log("Page count", payload, response);
```
How can I resolve this? If you propose a fix, please make it concise.| // const refreshPagination = (regenerateFlag: boolean = false) => { | ||
| // // This would typically call a pagination composable | ||
| // // For now, it's a placeholder | ||
| // console.log("Refreshing pagination", regenerateFlag); | ||
| // }; |
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.
style: Remove commented-out placeholder code
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/src/composables/useLogs/useSearchResponseHandler.ts
Line: 610:614
Comment:
**style:** Remove commented-out placeholder code
How can I resolve this? If you propose a fix, please make it concise.|
|
||
| if (searchObj.data.isOperationCancelled) { | ||
| // 3. Execute the search through connection manager | ||
| connectionManager.getDataThroughStream(queryReq, isPagination, callbacks); |
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.
logic: connectionManager.getDataThroughStream method may not exist if the split composable isn't implemented.
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/src/composables/useLogs/useSearchStream.ts
Line: 81:81
Comment:
**logic:** connectionManager.getDataThroughStream method may not exist if the split composable isn't implemented.
How can I resolve this? If you propose a fix, please make it concise.|
|
||
| const traceIdMapper = ref<{ [key: string]: string[] }>({}); | ||
|
|
||
| const useValuesWebSocket = () => { |
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.
style: Consider renaming this function from useValuesWebSocket to useValuesStreaming or similar since WebSocket functionality has been completely removed
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/src/composables/dashboard/useValuesWebSocket.ts
Line: 10:10
Comment:
**style:** Consider renaming this function from `useValuesWebSocket` to `useValuesStreaming` or similar since WebSocket functionality has been completely removed
How can I resolve this? If you propose a fix, please make it concise.| const initializeSearchConnection = ( | ||
| payload: any, | ||
| ): string | Promise<void> | null => { | ||
| if (searchObj.communicationMethod === "streaming") { | ||
| payload.searchType = "ui"; | ||
| payload.pageType = searchObj.data.stream.streamType; | ||
| return fetchQueryDataWithHttpStream(payload, { | ||
| data: (payload: any, response: any) => { | ||
| if (payload.onData) payload.onData(payload, response); | ||
| }, | ||
| error: (payload: any, error: any) => { | ||
| if (payload.onError) payload.onError(payload, error); | ||
| }, | ||
| complete: (payload: any, response: any) => { | ||
| if (payload.onComplete) payload.onComplete(payload, response); | ||
| }, | ||
| reset: (data: any, traceId?: string) => { | ||
| if (payload.onReset) payload.onReset(data, traceId); | ||
| }, | ||
| }) as Promise<void>; | ||
| } | ||
|
|
||
| return null; | ||
| }; |
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.
logic: Function only handles streaming case but returns null for non-streaming, which could cause issues when checking !requestId later
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/src/composables/useLogs/useSearchConnection.ts
Line: 70:93
Comment:
**logic:** Function only handles streaming case but returns null for non-streaming, which could cause issues when checking `!requestId` later
How can I resolve this? If you propose a fix, please make it concise.| if (shouldGetPageCount(queryReq) && searchObj.meta.refreshInterval == 0) { | ||
| queryReq.query.size = queryReq.query.size + 1; | ||
| } |
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.
logic: Direct mutation of input parameter queryReq.query.size could cause unintended side effects
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/src/composables/useLogs/useSearchConnection.ts
Line: 174:176
Comment:
**logic:** Direct mutation of input parameter `queryReq.query.size` could cause unintended side effects
How can I resolve this? If you propose a fix, please make it concise.| const requestId = initializeSearchConnection(payload); | ||
|
|
||
| if (!requestId) { | ||
| throw new Error( | ||
| `Failed to initialize ${searchObj.communicationMethod} connection`, | ||
| ); | ||
| } |
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.
logic: Type mismatch: initializeSearchConnection returns Promise<void> for streaming, but checking for truthy requestId
Prompt To Fix With AI
This is a comment left during a code review.
Path: web/src/composables/useLogs/useSearchConnection.ts
Line: 187:193
Comment:
**logic:** Type mismatch: `initializeSearchConnection` returns `Promise<void>` for streaming, but checking for truthy `requestId`
How can I resolve this? If you propose a fix, please make it concise.c9f108f to
b125de2
Compare
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 1 test failed | 26 | 21 | 1 | 3 | 1 | 81% | 2m 28s |
Test Failure Analysis
- visualize.spec.js: Test fails due to timeout waiting for element visibility
- logs testcases should render line chart for SELECT * query and save to dashboard with correct query in inspector: Locator not found within timeout period.
Root Cause Analysis
- The recent changes in src/.../cache/cacher.rs may have affected the rendering of the line chart, leading to the timeout issue.
Recommended Actions
- Increase the timeout duration for visibility checks in visualize.spec.js to accommodate potential delays.
- Verify that the SQL query execution completes successfully before checking for element visibility.
- Ensure that the element with the specified role and name is present in the DOM after the query execution.
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 4 tests failed | 232 | 212 | 4 | 15 | 1 | 91% | 3m 29s |
Test Failure Analysis
-
dashboard-streaming.spec.js: Timeout issues while waiting for elements to become visible
- dashboard streaming testcases should verify the custom value search from variable dropdown with streaming enabled: Timeout waiting for selector '[data-test="general-settings-enable-streaming"]' to be visible
-
dashboard-transpose.spec.js: Assertion failure due to unexpected error count
- dashboard UI testcases should not show an error when transpose is enabled from config with custom SQL query: Expected error count 0 but received 1
-
dashboard-filter.spec.js: Assertion failure on API call responses
- dashboard filter testcases should verify the custom value search from variable dropdown: Expected at least one API call but received 0
...and 1 additional failing spec. Visit the TestDino platform for a full breakdown.
Root Cause Analysis
- The changes in
src/.../meta/search.rsandsrc/.../search/multi_streams.rsmay have affected the expected behavior of the dashboard functionalities, leading to assertion failures and timeouts.
Recommended Actions
- Investigate the visibility of the element '[data-test="general-settings-enable-streaming"]' in dashboard-streaming.spec.js to resolve the timeout issue.
- Review the error handling logic in dashboard-transpose.spec.js to ensure the correct error count is being reported.
- Ensure that the API calls in dashboard-filter.spec.js are being made correctly and returning expected results.
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 4 tests failed | 232 | 212 | 4 | 15 | 1 | 91% | 3m 29s |
Test Failure Analysis
-
dashboard-streaming.spec.js: Timeout issues waiting for element visibility
- dashboard streaming testcases should verify the custom value search from variable dropdown with streaming enabled: Timeout waiting for '[data-test="general-settings-enable-streaming"]' to be visible.
-
dashboard-transpose.spec.js: Assertion failure due to unexpected error count
- dashboard UI testcases should not show an error when transpose is enabled from config with custom SQL query: Expected error count 0 but received 1.
-
dashboard-filter.spec.js: Assertion failure due to no captured API calls
- dashboard filter testcases should verify the custom value search from variable dropdown: Expected at least one API call but received 0.
...and 1 additional failing spec. Visit the TestDino platform for a full breakdown.
Root Cause Analysis
- The changes in
src/.../meta/search.rsandsrc/.../search/multi_streams.rsmay have affected the expected behavior of the dashboard functionalities, leading to timeouts and assertion failures.
Recommended Actions
- Investigate the visibility of the element '[data-test="general-settings-enable-streaming"]' in dashboard-streaming.spec.js to resolve timeout issues.
- Review the error handling logic in dashboard-transpose.spec.js to ensure the expected error count aligns with actual results.
- Ensure that the API calls are correctly captured in dashboard-filter.spec.js to avoid assertion failures related to the response length.
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 4 tests failed | 232 | 211 | 4 | 15 | 2 | 91% | 3m 29s |
Test Failure Analysis
-
dashboard-streaming.spec.js: Test fails due to timeout waiting for element visibility
- dashboard streaming testcases should verify the custom value search from variable dropdown with streaming enabled: Timeout waiting for '[data-test="general-settings-enable-streaming"]' to be visible.
-
dashboard-transpose.spec.js: Assertion failure when checking error counts
- dashboard UI testcases should not show an error when transpose is enabled from config with custom SQL query: Expected error count to be 0, but received 1.
-
dashboard-filter.spec.js: Assertion failure on API call responses
- dashboard filter testcases should verify the custom value search from variable dropdown: Expected at least one API call, but received 0.
...and 1 additional failing spec. Visit the TestDino platform for a full breakdown.
Root Cause Analysis
- The code changes in src/.../search/multi_streams.rs may have introduced issues affecting element visibility and API response handling.
Recommended Actions
- Investigate the visibility of the element '[data-test="general-settings-enable-streaming"]' in dashboard-streaming.spec.js to resolve the timeout issue.
- Review the logic for error counting in dashboard-transpose.spec.js to ensure it correctly reflects the expected outcomes.
- Ensure that the API calls in dashboard-filter.spec.js are being made correctly and returning expected results.
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 4 tests failed | 232 | 210 | 4 | 15 | 3 | 91% | 3m 29s |
Test Failure Analysis
-
dashboard-streaming.spec.js: Timeout issues while waiting for UI elements to become visible
- dashboard streaming testcases should verify the custom value search from variable dropdown with streaming enabled: Timeout waiting for locator '[data-test="general-settings-enable-streaming"]' to be visible.
-
dashboard-transpose.spec.js: Assertion failure due to unexpected error count
- dashboard UI testcases should not show an error when transpose is enabled from config with custom SQL query: Expected error count 0 but received 1.
-
dashboard-filter.spec.js: Assertion failure due to no captured API calls
- dashboard filter testcases should verify the custom value search from variable dropdown: Expected at least one API call but received 0.
...and 1 additional failing spec. Visit the TestDino platform for a full breakdown.
Root Cause Analysis
- The code changes in src/.../search/multi_streams.rs may have introduced issues affecting the expected behavior of the dashboard functionalities.
Recommended Actions
- Investigate the visibility of the element '[data-test="general-settings-enable-streaming"]' in dashboard-streaming.spec.js to resolve the timeout issue.
- Review the error handling logic in dashboard-transpose.spec.js to ensure the expected error counts are accurate.
- Check the API call logic in dashboard-filter.spec.js to confirm that responses are being captured correctly.
Test Run FailedAuthor: Testdino Test Results
Test Failure Analysis
Root Cause Analysis
Recommended Actions
|
50689dd to
a089830
Compare
Test Run FailedAuthor: Testdino Test Results
Test Failure Analysis
Root Cause Analysis
Recommended Actions
|
a089830 to
3ce0da5
Compare
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 2 tests failed | 33 | 29 | 2 | 1 | 1 | 88% | 2m 17s |
Test Failure Analysis
- dashboard-transpose.spec.js: Assertion failure due to unexpected error count
- dashboard UI testcases should not show an error when transpose is enabled from config with custom SQL query: Expected error count to be 0, but got 1.
- dashboard-filter.spec.js: Assertion failure from missing API responses
- dashboard filter testcases should verify the custom value search from variable dropdown: Expected valuesResponses length to be greater than 0, but got 0.
Root Cause Analysis
- The changes in src/.../search/multi_streams.rs and src/.../cache/cacher.rs may have affected the expected API responses, leading to assertion failures.
Recommended Actions
- Investigate the changes in src/.../search/multi_streams.rs to ensure the correct number of streams is returned.
- Check the API response handling in src/.../cache/cacher.rs to confirm that the expected data is being populated correctly.
- Add additional logging in the tests to capture the state of valuesResponses before assertions.
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 2 tests failed | 33 | 27 | 2 | 1 | 3 | 82% | 2m 10s |
Test Failure Analysis
- dashboard-transpose.spec.js: Assertion failures due to unexpected error counts
- dashboard UI testcases should not show an error when transpose is enabled from config with custom SQL query: Expected error count 0 but received 1.
- dashboard-filter.spec.js: Assertion failures due to no captured API responses
- dashboard filter testcases should verify the custom value search from variable dropdown: Expected at least one response but received 0.
Root Cause Analysis
- The changes in
src/.../meta/search.rsandsrc/.../search/multi_streams.rsmay have affected the expected error handling and API response counts.
Recommended Actions
- Investigate the logic for error handling in
src/.../meta/search.rsto ensure correct error counts are returned. 2. Review the API response collection insrc/.../search/multi_streams.rsto confirm that responses are being captured correctly. 3. Add additional logging in both files to trace the flow of data and identify where counts may be miscalculated.
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 2 tests failed | 33 | 28 | 2 | 1 | 2 | 85% | 2m 8s |
Test Failure Analysis
- dashboard-transpose.spec.js: Assertion failure due to unexpected error count
- dashboard UI testcases should not show an error when transpose is enabled from config with custom SQL query: Expected error count to be 0, but received 1.
- dashboard-filter.spec.js: Assertion failure due to no API call responses
- dashboard filter testcases should verify the custom value search from variable dropdown: Expected at least one API call response, but received 0.
Root Cause Analysis
- The changes in
src/.../meta/search.rsandsrc/.../search/multi_streams.rsmay have affected the expected API response structure, leading to assertion failures in tests.
Recommended Actions
- Investigate the handling of
transposeErrorResultindashboard-transpose.spec.jsto ensure it correctly reflects the error count. 2. Review the API call logic indashboard-filter.spec.jsto confirm that the expected responses are being generated and returned properly.
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 1 test failed | 60 | 51 | 1 | 4 | 4 | 85% | 2m 9s |
Test Failure Analysis
- dashboard-filter.spec.js: Assertion failure due to no API calls captured
- dashboard filter testcases should verify the custom value search from variable dropdown: Expected at least one API call, but received zero.
Root Cause Analysis
- The change from an object to an array in usePanelDataLoader.ts may have affected how responses are collected, leading to zero API calls.
Recommended Actions
- Review the logic in usePanelDataLoader.ts to ensure responses are correctly pushed to the array. 2. Add logging to track API call responses in dashboard-filter.spec.js. 3. Verify that the API endpoint is functioning correctly and returning expected results.
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 1 test failed | 60 | 54 | 1 | 4 | 1 | 90% | 2m 14s |
Test Failure Analysis
- dashboard-filter.spec.js: Assertion failure due to no API call responses captured
- dashboard filter testcases should verify the custom value search from variable dropdown: Expected at least one API call response, but received none.
Root Cause Analysis
- The addition of the
query_indexfield insrc/.../meta/search.rsmay have impacted the API response handling, leading to zero responses.
Recommended Actions
- Investigate the API call logic in
dashboard-filter.spec.jsto ensure it correctly captures responses. 2. Review the changes insrc/.../meta/search.rsfor potential issues in response generation. 3. Add logging to track API call responses during the test execution.
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 1 test failed | 60 | 52 | 1 | 4 | 3 | 87% | 4m 1s |
Test Failure Analysis
- dashboard-filter.spec.js: Assertion failure due to no API calls captured
- dashboard filter testcases should verify the custom value search from variable dropdown: Expected at least one API call, but received zero.
Root Cause Analysis
- The addition of new fields in
src/.../meta/search.rsmay have impacted the API response structure, leading to no captured calls.
Recommended Actions
- Investigate the API response to ensure it returns expected data for the test case. 2. Review the changes in
src/.../meta/search.rsto confirm if the new fields affect the API call logic. 3. Add logging around the API call to capture the response for debugging.
eabd147 to
ab7a6d4
Compare
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 1 test failed | 201 | 187 | 1 | 11 | 2 | 93% | 3m 31s |
Test Failure Analysis
- dashboard-streaming.spec.js: Timeout issues while waiting for element visibility
- dashboard streaming testcases should verify the custom value search from variable dropdown with streaming enabled: Timeout waiting for locator '[data-test="general-settings-enable-streaming"]' to be visible.
Root Cause Analysis
- The test was skipped in the recent changes to dashboard-filter.spec.js, indicating potential instability in the related tests.
Recommended Actions
- Investigate the visibility of the element '[data-test="general-settings-enable-streaming"]' in the UI during the test execution.
- Increase the timeout duration in the test to accommodate slower loading times.
- Ensure that the streaming feature is properly initialized before running the tests.
ab7a6d4 to
49b69b2
Compare
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| 1 test failed | 125 | 110 | 1 | 12 | 2 | 88% | 4m 28s |
Test Failure Analysis
- maxquery.spec.js: Timeout errors due to element visibility issues
- dashboard max query testcases should correctly display max query range error message when max query range is exceeded: Locator timeout - waiting for '[data-test="general-settings-enable-streaming"]' to be visible.
Root Cause Analysis
- The code changes in dashboard-streaming.spec.js comment out the streaming state settings, likely causing the timeout issue.
Recommended Actions
- Re-enable the streaming state settings in dashboard-streaming.spec.js to ensure elements are visible before tests run. 2. Increase the timeout duration in the waitForSelector method if the element takes longer to appear. 3. Verify the presence and visibility of the '[data-test="general-settings-enable-streaming"]' element in the UI before executing the test.
This reverts commit 068716e.
4a59758 to
6148323
Compare
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| All tests passed | 366 | 338 | 0 | 21 | 7 | 92% | 7m 45s |
|
| Status | Total | Passed | Failed | Skipped | Flaky | Pass Rate | Duration |
|---|---|---|---|---|---|---|---|
| All tests passed | 376 | 350 | 0 | 21 | 5 | 93% | 5m 32s |
Removed HTTP API support from the UI. The backend API will remain unchanged, and the UI will now communicate exclusively through the streaming API.