web/src/composables/useLogs.ts (2)

1705-1714: Approved with nitpicks

The code changes look good functionally. A couple of suggestions:

1. Add a comment explaining the purpose of the setTimeout when handling multiple partitions.
2. The await inside setTimeout looks unusual. Consider refactoring it or add a comment if this pattern is needed for some reason.

---

2372-2389: Approved with a minor refactoring suggestion

The code changes look good. One small suggestion:
Consider changing the map to a for...of loop for better performance. Something like:

for (const [index, item] of searchObj.data.queryResults.partitionDetail.partitions.entries()) {
  if (item[0] == currentStartTime && item[1] == currentEndTime) {
    totalHits = res.data.hits.reduce(
      (accumulator, currentValue) => accumulator + Math.max(parseInt(currentValue.zo_sql_num, 10), 0),
      0
    );
    searchObj.data.queryResults.partitionDetail.partitionTotal[index] = totalHits;
    break;
  }
}

This avoids creating a new function on each iteration. But it's a minor nitpick, the current code is fine too.

Configuration used: CodeRabbit UI
Review profile: CHILL

web/src/composables/useLogs.ts (3)

Line range hint 1-2500: Consider decomposing useLogs into smaller focused functions

The useLogs function is quite large with many responsibilities. Consider breaking it down further into smaller focused functions based on logical areas of responsibility. This will improve readability, maintainability and testability of the code.

For example, you could have separate composable functions like:

• useSearchState - manages the reactive searchObj and related state
• useStreamData - handles retrieving and updating stream data
• useQueryData - responsible for running queries and updating results
• useHistogramData - handles histogram data generation and updates
• useURLParams - manages syncing state with URL query params

And so on. The useLogs function can then compose these together.

Recommend adding types for searchObj and other variables/functions

To improve readability and catch potential bugs, consider adding TypeScript types for the key objects like searchObj, searchAggData, fieldValues etc.

You can define interfaces like:

interface SearchObj {
  organizationIdentifier: string;
  runQuery: boolean;
  loading: boolean;
  // ...
}

And use it to type the searchObj:

const searchObj: SearchObj = reactive({
  // ...
});

Also add types for function parameters and return values.

Propose moving SQL parser import logic outside

To declutter the useLogs function, consider moving the SQL parser import logic to a separate composable or service.

For example:

// useSqlParser.ts
import { sqlParser } from "@/composables/useParser";

export default function useSqlParser() {  
  const parser = ref();

  async function initSqlParser() {
    parser.value = await sqlParser();
  }

  return {
    parser,
    initSqlParser,
  }
}

And in useLogs:

import useSqlParser from "./useSqlParser";

export default function useLogs() {
  const { parser, initSqlParser } = useSqlParser();

  onBeforeMount(() => {
    initSqlParser();
    // ...
  });

  // ...
}

This keeps the SQL parser logic separate and makes the code more modular.

---

Line range hint 1800-2000: Consider decomposing getQueryData into smaller focused functions

The getQueryData function is quite long and has multiple responsibilities. Consider breaking it down into smaller focused functions to improve readability and maintainability.

For example, you could extract the logic for resetting query data, getting partitions, fetching paginated data, updating histogram data, etc into separate functions.

Something like:

async function getQueryData(isPagination = false) {
  try {
    if (!isPagination) {
      resetQueryData();
      await getQueryPartitions(queryReq);
    }

    await fetchPaginatedData(queryReq);
    await updateHistogramData();
    await updateTotalCounts();

    // ...
  }
  // ...
}

This makes the main function more readable and the individual steps more reusable and testable.

Refactor the duplicated partition update logic

There is some duplicated logic for updating the partition totals in the getQueryData function:

for (const [index, item] of searchObj.data.queryResults.partitionDetail.partitions.entries()) {
  if (searchObj.data.queryResults.partitionDetail.partitionTotal[index] == -1 && 
      queryReq.query.start_time == item[0]) {
    searchObj.data.queryResults.partitionDetail.partitionTotal[index] = res.data.total;
  }
}

This block appears multiple times. Consider refactoring it into a separate function for reuse:

function updatePartitionTotals(partitions, totals, startTime, total) {
  for (const [index, item] of partitions.entries()) {
    if (totals[index] == -1 && startTime == item[0]) {
      totals[index] = total;
    }
  }
}

And then use it like:

updatePartitionTotals(
  searchObj.data.queryResults.partitionDetail.partitions,
  searchObj.data.queryResults.partitionDetail.partitionTotal, 
  queryReq.query.start_time,
  res.data.total
);

Improve error handling with more specific messages

The getQueryData function has a generic catch block that logs the error and shows a generic "Something went wrong" notification:

} catch (e: any) {
  searchObj.loading = false;
  showErrorNotification("Error occurred during the search operation.");
  notificationMsg.value = "";
}

Consider providing more specific error messages based on the type of error. For example:

} catch (e: any) {
  searchObj.loading = false;
  
  if (e instanceof QueryPartitionError) {
    showErrorNotification("Error retrieving query partitions: " + e.message);
  } else if (e instanceof PaginationError) {
    showErrorNotification("Error retrieving paginated data: " + e.message);
  } else {
    showErrorNotification("An unexpected error occurred during the search operation");
  }

  notificationMsg.value = "";
}

This will make it easier to diagnose and fix issues.

Tools

Biome

[error] 1373-1373: Do not access Object.prototype method 'hasOwnProperty' from target object.

It's recommended using Object.hasOwn() instead of using Object.hasOwnProperty().
See MDN web docs for more details.

(lint/suspicious/noPrototypeBuiltins)

---

Line range hint 2900-3000: Add types for variables

Consider adding types for the variables in the generateHistogramData function to improve type safety and readability.

For example:

let num_records: number = 0;
const unparsed_x_data: (string | number)[] = [];
const xData: number[] = [];
const yData: number[] = [];

This makes it clear what type of data each variable holds.

Improve error handling with more specific messages

The generateHistogramData function has a generic catch block that logs the error and shows a generic "Error while generating histogram data" notification:

} catch (e: any) {
  console.log("Error while generating histogram data", e);
  notificationMsg.value = "Error while generating histogram data.";
}

Consider providing more specific error messages based on the type of error. For example:

} catch (e: any) {
  if (e instanceof DataMappingError) {
    console.log("Error mapping histogram data:", e);
    notificationMsg.value = "Error mapping histogram data. Please try again.";
  } else {
    console.log("Unexpected error generating histogram data:", e);
    notificationMsg.value = "An unexpected error occurred while generating the histogram. Please try again.";
  }
}

This will make it easier to diagnose and fix issues.

Tools

Biome

[error] 1373-1373: Do not access Object.prototype method 'hasOwnProperty' from target object.

It's recommended using Object.hasOwn() instead of using Object.hasOwnProperty().
See MDN web docs for more details.

(lint/suspicious/noPrototypeBuiltins)

Configuration used: CodeRabbit UI
Review profile: CHILL

web/src/composables/useLogs.ts (1)

1710-1714: Asynchronous histogram regeneration looks good, but consider a dynamic delay.

Calling generateHistogramData and refreshPartitionPagination asynchronously after processing the partitions is a good approach to regenerate the histogram. The 100ms delay provides a small buffer for the processing to complete.

However, consider calculating the delay dynamically based on the number of partitions and query complexity. This will ensure the histogram is regenerated after processing is fully complete, even for a large number of partitions or complex queries.

Configuration used: CodeRabbit UI
Review profile: CHILL