apps/kyb-app/src/hooks/useEndUserQuery/useEndUserQuery.ts (2)

24-46: Add null checks for user properties

While the monitoring integration is well-structured, it's important to validate user properties before usage.

   useEffect(() => {
-    if (endUser) {
+    if (endUser?.id && endUser?.email && endUser?.firstName && endUser?.lastName) {
       updateSentryUser({
         id: endUser.id,
         email: endUser.email,
         fullName: `${endUser.firstName} ${endUser.lastName}`,
       });

---

Line range hint 48-53: Consider using type guard for error handling

The current error casting could be improved using a type guard for better type safety.

-    error: error ? (error as HTTPError) : null,
+    error: error instanceof HTTPError ? error : null,

apps/kyb-app/src/common/utils/request.ts (1)

29-37: Optimize response handling and improve error clarity

The code makes multiple calls to response.clone() and might silently ignore parsing errors.

Consider consolidating the response handling:

-responseBody = await error.response.clone().text();
-const responseJson = await error.response.clone().json();
+const clonedResponse = error.response.clone();
+responseBody = await clonedResponse.text();
+let responseJson;
+try {
+  responseJson = JSON.parse(responseBody);
+} catch (parseError) {
+  console.warn('Failed to parse error response as JSON:', responseBody);
+  throw error;
+}

apps/kyb-app/src/initialize-monitoring/initialize-monitoring.ts (1)

53-63: Add input validation and document the fullName mapping.

While the function works correctly, consider these improvements:

1. Add input validation to ensure data quality before sending to Sentry
2. Document why fullName is mapped to username in Sentry context

 export const updateSentryUser = (userMetadata: {
   id?: string;
   email?: string;
   fullName?: string;
 }) => {
+  // Validate inputs
+  if (userMetadata.email && !userMetadata.email.includes('@')) {
+    console.warn('Invalid email format provided to updateSentryUser');
+    return;
+  }
+
+  // Map fullName to username for Sentry's conventional user context structure
   Sentry.setUser({
     id: userMetadata.id,
     email: userMetadata.email,
     username: userMetadata.fullName,
   });
 };

apps/kyb-app/src/domains/collection-flow/collection-flow.api.ts (3)

Line range hint 13-26: Consider enhancing error logging with additional context

While the PostHog error handling is properly isolated, consider adding more context to the error logging to align with the PR's objective of improving monitoring metadata.

     } catch (error) {
-      console.error('Error identifying user in PostHog:', error);
+      console.error('Error identifying user in PostHog:', {
+        error,
+        userId: user.id,
+        context: 'fetchUser',
+      });
     }

---

Line range hint 95-111: Add consistent error handling to new user management functions

The new user-related functions lack error handling, which is inconsistent with the error handling pattern used in fetchFlowContext. Consider adding proper error handling to align with the PR's objective of managing response exceptions.

 export const fetchEndUser = async (): Promise<EndUser> => {
-  const result = await request.get('collection-flow/user');
-  return result.json<EndUser>();
+  try {
+    const result = await request.get('collection-flow/user');
+    const user = await result.json<EndUser>();
+    
+    if (!user || typeof user !== 'object') {
+      throw new Error('Invalid user data received');
+    }
+    
+    return user;
+  } catch (error) {
+    console.error('Error fetching end user:', error);
+    throw error;
+  }
 };

 export interface CreateEndUserDto {
   email: string;
   firstName: string;
   lastName: string;
 }

 export const createEndUserRequest = async ({ email, firstName, lastName }: CreateEndUserDto) => {
-  await request.post('collection-flow/no-user', { json: { email, firstName, lastName } });
+  try {
+    await request.post('collection-flow/no-user', { json: { email, firstName, lastName } });
+  } catch (error) {
+    console.error('Error creating end user:', {
+      error,
+      context: 'createEndUserRequest',
+      email,
+    });
+    throw error;
+  }
 };

---

Line range hint 41-93: Standardize error handling across all API functions

The file shows inconsistent error handling patterns. While fetchFlowContext implements proper error handling with response validation, other functions like fetchUISchema, updateLanguage, and fetchCustomer lack similar protections.

Consider implementing a consistent error handling strategy across all API functions:

1. Validate response data
2. Add proper error context
3. Handle specific error cases that can be safely skipped (as per PR objectives)

Example pattern to follow:

const apiHandler = async <T>(
  operation: () => Promise<T>,
  context: string,
  validate?: (data: T) => boolean
): Promise<T> => {
  try {
    const result = await operation();
    if (validate && !validate(result)) {
      throw new Error(`Invalid ${context} data`);
    }
    return result;
  } catch (error) {
    if (shouldSkipError(error)) {
      console.warn(`Skipping handled error in ${context}:`, error);
      return null as T;
    }
    console.error(`Error in ${context}:`, error);
    throw error;
  }
};

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Check how HTTPError is used across the codebase for consistency

# Check for HTTPError imports
echo "Checking HTTPError imports:"
rg --type ts "import.*HTTPError.*from 'ky'" -A 2

# Check for error handling patterns
echo "\nChecking error handling patterns:"
ast-grep --pattern 'catch ($error) { $$$}' --lang ts

#!/bin/bash
# Let's check the error handling patterns with a more specific search

# Check how HTTPError is used in catch blocks
echo "Checking HTTPError usage in catch blocks:"
rg --type ts "catch.*\(.*HTTPError" -A 3

# Check the implementation of error handling function
echo "\nChecking error handling implementation:"
rg --type ts "isExceptionWillBeHandled" -A 3

#!/bin/bash
# Let's check for other error handling patterns in the codebase

# Check for error handling in try-catch blocks
echo "Checking try-catch blocks with HTTPError:"
rg --type ts "try\s*{[^}]*}\s*catch.*HTTPError" -A 5

# Check for other HTTP error types being used
echo "\nChecking for other HTTP error types:"
rg --type ts "import.*Error.*from" -A 2

# Check where the request utility is used
echo "\nChecking request utility usage:"
rg --type ts "import.*request.*from.*utils/request" -A 2

export const isExceptionWillBeHandled = (error: HTTPError) => {
  return error.message === 'No EndUser is set for this token';
};

#!/bin/bash
# Description: Verify the implementation of isExceptionWillBeHandled helper

# Search for the helper function implementation
ast-grep --pattern 'export const isExceptionWillBeHandled = $_'

# Search for any tests covering this helper
rg -l "isExceptionWillBeHandled.*test" -g "*.{ts,tsx,js,jsx}"