Skip to content

Known Issues*Β #166

@CodingAleCR

Description

@CodingAleCR

Known Issues in http_interceptor

This document outlines the remaining issues found in the codebase that should be addressed for improved robustness and reliability.

πŸ”§ Issues by Priority

High Priority Issues

1. Potential Memory Leak: Timer Not Always Cancelled

Location: lib/http/intercepted_client.dart lines 340-348
Status: ⚠️ Needs Investigation

Issue: The timeout timer might not be cancelled in all code paths, potentially causing memory leaks.

timeoutTimer = Timer(requestTimeout!, () {
  // ... timeout logic ...
});

requestFuture.then((streamResponse) {
  timeoutTimer?.cancel(); // βœ… Cancelled here
  // ... code ...
}).catchError((error) {
  timeoutTimer?.cancel(); // βœ… Cancelled here
  // ... code ...
});

Risk: If the completer is completed through the timeout callback, the timer might not be cancelled in all scenarios.

Suggested Fix: Ensure timer cancellation in all completion paths and add proper cleanup.


2. Race Condition: Completer State Management

Location: lib/http/intercepted_client.dart lines 310-350
Status: ⚠️ Needs Investigation

Issue: Multiple code paths can complete the same completer, potentially causing race conditions.

if (!completer.isCompleted) {
  completer.complete(response);
}

Risk: Multiple threads or async operations could try to complete the same completer simultaneously.

Suggested Fix: Add proper synchronization or use atomic operations for completer state management.


Medium Priority Issues

3. Potential Null Reference: Request Body Handling

Location: lib/http/intercepted_client.dart lines 240-251
Status: πŸ”§ Needs Improvement

Issue: The body type checking doesn't handle all possible null cases properly.

if (body != null) {
  if (body is String) {
    request.body = body;
  } else if (body is List) {
    request.bodyBytes = body.cast<int>(); // ❌ Could fail if List is null
  } else if (body is Map) {
    request.bodyFields = body.cast<String, String>(); // ❌ Could fail if Map is null
  } else {
    throw ArgumentError('Invalid request body "$body".');
  }
}

Suggested Fix: Add null checks and better type validation.


4. Inconsistent Error Handling: StreamedResponse Type Check

Location: lib/http/intercepted_client.dart lines 220-227
Status: πŸ”§ Needs Improvement

Issue: The type check for StreamedResponse throws a generic ClientException instead of a more specific error.

if (interceptedResponse is StreamedResponse) {
  return interceptedResponse;
}

throw ClientException(
  'Expected `StreamedResponse`, got ${interceptedResponse.runtimeType}.',
);

Impact: This makes debugging harder as the error message doesn't provide enough context.

Suggested Fix: Create a more specific exception type or improve error messages.


5. Potential Issue: URL Parameter Encoding

Location: lib/utils/query_parameters.dart lines 42-60
Status: πŸ”§ Needs Investigation

Issue: The URL parameter encoding logic might not handle all edge cases properly.

parameters.forEach((key, value) {
  final encodedKey = Uri.encodeQueryComponent(key);
  
  if (value is List) {
    // ... list handling ...
  } else if (value is String) {
    url += "$encodedKey=${Uri.encodeQueryComponent(value)}&";
  } else {
    url += "$encodedKey=${Uri.encodeQueryComponent(value.toString())}&";
  }
});

Risk: If value.toString() returns null or throws an exception, this could cause issues.

Suggested Fix: Add proper null checks and exception handling.


Low Priority Issues

6. Potential Issue: Retry Policy State Management

Location: lib/http/intercepted_client.dart lines 360-380
Status: πŸ”§ Needs Improvement

Issue: The retry count is reset for each new request, but there's no validation that retry attempts don't exceed reasonable limits.

_retryCount = 0; // Reset retry count for each new request

Risk: A malicious retry policy could cause infinite loops or excessive retries.

Suggested Fix: Add maximum retry limits and validation.


7. Minor Issue: Inconsistent Exception Types

Location: lib/models/http_interceptor_exception.dart
Status: πŸ”§ Needs Improvement

Issue: The custom exception class uses dynamic for the message, which could lead to type safety issues.

class HttpInterceptorException implements Exception {
  final dynamic message; // ❌ Should be String?
  
  HttpInterceptorException([this.message]);
}

Suggested Fix: Change to String? for better type safety.


8. Potential Issue: Extension Type Safety

Location: lib/extensions/base_request.dart lines 15-70
Status: πŸ”§ Needs Improvement

Issue: The copyWith method uses dynamic for the body parameter, which could cause runtime errors.

BaseRequest copyWith({
  // ... other parameters ...
  dynamic body, // ❌ Should be more specific
  // ... other parameters ...
}) {
  // ... implementation ...
}

Suggested Fix: Use more specific types or add runtime type checking.


9. Minor Issue: Missing Validation in HTTP Methods

Location: lib/http/http_methods.dart lines 15-29
Status: πŸ”§ Needs Improvement

Issue: The fromString method doesn't handle case-insensitive parsing or trim whitespace.

static HttpMethod fromString(String method) {
  switch (method) { // ❌ Case-sensitive, no trimming
    case "HEAD":
      return HttpMethod.HEAD;
    // ... other cases ...
  }
  throw ArgumentError.value(method, "method", "Must be a valid HTTP Method.");
}

Suggested Fix: Add case-insensitive parsing and whitespace trimming.


πŸ§ͺ Testing Issues

Test Coverage Gaps

10. Missing Edge Case Tests

Status: πŸ“ Needs Additional Tests

Areas needing more test coverage:

  • Timer cancellation edge cases
  • Completer race condition scenarios
  • Null body handling
  • Malformed URL parameter handling
  • Retry policy edge cases
  • Exception type validation

Suggested Action: Add comprehensive edge case tests for all identified issues.


πŸ“‹ Action Items

Immediate Actions (High Priority)

  1. πŸ”§ Investigate and fix timer cancellation issues
  2. πŸ”§ Add proper synchronization for completer state management

Short-term Actions (Medium Priority)

  1. πŸ”§ Improve request body handling with better null checks
  2. πŸ”§ Create more specific exception types for better error handling
  3. πŸ”§ Add comprehensive URL parameter encoding validation
  4. πŸ”§ Add retry policy validation and limits

Long-term Actions (Low Priority)

  1. πŸ”§ Improve type safety in exception classes
  2. πŸ”§ Add case-insensitive HTTP method parsing
  3. πŸ”§ Enhance extension type safety
  4. πŸ“ Add comprehensive edge case tests

🎯 Success Criteria

For High Priority Issues

  • All timers are properly cancelled in all code paths
  • No race conditions in completer state management
  • Comprehensive tests for edge cases

For Medium Priority Issues

  • Robust null handling in request body processing
  • Specific and informative error messages
  • Validated URL parameter encoding

For Low Priority Issues

  • Improved type safety throughout the codebase
  • Better HTTP method parsing
  • Enhanced test coverage

πŸ“Š Issue Summary

Priority Count Status
High 2 1 Fixed, 1 Pending
Medium 3 All Pending
Low 4 All Pending
Testing 1 Pending

Total Issues: 10
Fixed: 1
Pending: 9


πŸ” Monitoring

Areas to Monitor

  1. Memory usage patterns in long-running applications
  2. Exception frequency and types in production
  3. Performance impact of retry policies
  4. URL encoding edge cases in real-world usage

Metrics to Track

  • Timer cancellation success rate
  • Completer completion patterns
  • Exception type distribution
  • Retry attempt frequency

πŸ“š References


Last Updated: [Current Date]
Status: Active Monitoring Required

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions