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

Line range hint 1267-1275: Refactor Error Handling to Reduce Redundancy

The error handling code between lines 1267-1275 is similar to other parts of the codebase. Consider creating a utility function to handle errors uniformly, reducing code duplication and improving maintainability.

You could create a function like handleError:

function handleError(err) {
  let errorMsg = '';
  let errorDetail = '';
  let trace_id = '';

  if (err.response != undefined) {
    errorMsg = err.response?.data?.error || err.response?.data?.message || '';
    errorDetail = err.response?.data?.error_detail || '';
    trace_id = err.response?.data?.trace_id || '';
  } else {
    errorMsg = err?.message || '';
    trace_id = err?.trace_id || '';
  }

  return { errorMsg, errorDetail, trace_id };
}

Then replace the error handling code:

- if (err.response != undefined) {
-   searchObj.data.errorMsg = err.response?.data?.error || err.response?.data?.message || "";
-   if (err.response.data.hasOwnProperty("error_detail")) {
-     searchObj.data.errorDetail = err.response.data.error_detail;
-   }
-   if (err.response.data.hasOwnProperty("trace_id")) {
-     trace_id = err.response.data?.trace_id;
-   }
- } else {
-   searchObj.data.errorMsg = err.message;
-   if (err.hasOwnProperty("trace_id")) {
-     trace_id = err?.trace_id;
-   }
- }
+ const { errorMsg, errorDetail, trace_id } = handleError(err);
+ searchObj.data.errorMsg = errorMsg;
+ searchObj.data.errorDetail = errorDetail;

🧰 Tools

🪛 Biome

[error] 1268-1268: 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 1285-1290: Avoid Overwriting Error Messages

At line 1285, searchObj.data.errorMsg is reassigned inside the if (err?.request?.status >= 429) block, potentially overwriting the error message set earlier. Ensure this reassignment is intentional or consider consolidating the error message assignments to prevent loss of information.

Consider adjusting the code:

if (err?.request?.status >= 429) {
  notificationMsg.value = err?.response?.data?.message;
- searchObj.data.errorMsg = err?.response?.data?.message || "";
  searchObj.data.errorDetail = err?.response?.data?.error_detail;
}

Or, if you need to update searchObj.data.errorMsg, ensure it doesn't unintentionally overwrite important messages.

---

2341-2344: Simplify Optional Chaining Usage

In lines 2341-2344, you can simplify the assignments using optional chaining to make the code cleaner.

Refactored code:

if (err?.request?.status >= 429) {
  notificationMsg.value = err?.response?.data?.message || "";
  searchObj.data.errorMsg = err?.response?.data?.message || "";
  searchObj.data.errorDetail = err?.response?.data?.error_detail || "";
}

This removes unnecessary lines and uses the || operator to provide default values.

Configuration used: CodeRabbit UI
Review profile: CHILL

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

2310-2311: Consider implementing a centralized error handling function

The TODO comment suggests creating a handleError function to consolidate error handling logic. This is a good idea that could improve code maintainability and consistency across the application.

Would you like assistance in designing and implementing the handleError function? This could involve:

1. Identifying common error handling patterns in the current code.
2. Designing a flexible function signature that can handle various error scenarios.
3. Implementing the function with proper TypeScript typing.
4. Updating existing error handling code to use the new function.

---

2319-2323: Comprehensive error handling improvements

These changes enhance the error handling in the getPaginatedData function by:

1. Using optional chaining (?.) to safely access nested properties.
2. Providing fallback values with the || operator.
3. Setting detailed error information on the searchObj.data object.

These improvements make the error handling more robust and consistent with the changes seen earlier in the file.

Once the handleError function mentioned in the TODO comment is implemented, consider refactoring this error handling code to use that centralized function. This would further improve consistency and maintainability across the application.

Example refactor (pseudo-code):

const { errorMsg, errorDetail, trace_id } = handleError(err);
searchObj.data.errorMsg = errorMsg;
searchObj.data.errorDetail = errorDetail;
searchObj.data.errorCode = err?.response?.data?.code || "";

Also applies to: 2329-2330, 2335-2338, 2347-2350

Configuration used: CodeRabbit UI
Review profile: CHILL

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

1288-1288: Consider consistent error message handling

While the use of optional chaining is good, consider aligning this line with the previous error handling pattern for consistency:

- searchObj.data.errorMsg = err?.response?.data?.message || "";
+ searchObj.data.errorMsg = err?.response?.data?.error || err?.response?.data?.message || "";

This change would make the error handling more consistent throughout the function.

---

2310-2311: Implement centralized error handling

The TODO comment suggests creating a handleError function to centralize error handling logic. This is a good practice that can improve code maintainability and reduce duplication.

Would you like assistance in implementing the handleError function? I can provide a basic implementation that aligns with the current error handling patterns in the code.

---

Line range hint 2319-2350: Improved error handling with optional chaining

The changes in this segment significantly improve the error handling by using optional chaining and providing fallback values consistently. This makes the code more robust against undefined property access errors.

To further improve the code, consider reducing duplication by extracting the common error handling logic into a separate function. For example:

function extractErrorInfo(err: any) {
  const errorMsg = err?.response?.data?.error || err?.response?.data?.message || err?.message || "Unknown error";
  const errorDetail = err?.response?.data?.error_detail || "";
  const traceId = err?.response?.data?.trace_id || err?.trace_id || "";
  return { errorMsg, errorDetail, traceId };
}

// Usage
const { errorMsg, errorDetail, traceId } = extractErrorInfo(err);
searchObj.data.errorMsg = errorMsg;
searchObj.data.errorDetail = errorDetail;
// ... use traceId as needed

This refactoring would make the error handling more consistent and easier to maintain across different parts of the code.

🧰 Tools

🪛 ast-grep

[warning] 2316-2316: The application creates a database connection with an empty password. This can lead to unauthorized access by either an internal or external malicious actor. To prevent this vulnerability, enforce authentication when connecting to a database by using environment variables to securely provide credentials or retrieving them from a secure vault or HSM (Hardware Security Module).
Context: "Error while processing histogram request."
Note: [CWE-287] Improper Authentication. [REFERENCES]
- https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

Configuration used: CodeRabbit UI
Review profile: CHILL