Skip to content

Conversation

@rolandb5
Copy link

Summary

  • Fix memory leak in segmentRange.Clear() that caused unbounded memory growth
  • The method was returning early on first error, leaving remaining segments unclosed
  • Now continues closing all segments and returns joined errors

Problem

When downloads stalled or failed, Clear() would exit on the first segment close error, leaving other segments open. Each unclosed segment holds buffers, causing memory to grow unbounded (observed 4+ GB growth in production).

Solution

  • Modified Clear() to iterate through all segments regardless of individual close errors
  • Collect all errors and return them joined using errors.Join()
  • Added comprehensive test coverage for edge cases

Testing

  • Added unit tests covering:
    • Empty range
    • Single segment (success/error)
    • Multiple segments (all success, all error, mixed)
    • Nil segment handling
  • Validated in production: memory stable at 20-50 MB over 9 hours (previously grew to 2.5 GB)

Impact

Critical fix - Without this, the container would eventually OOM during active streaming of large files.

🤖 Generated with Claude Code

The segmentRange.Clear() method was returning early on the first error,
leaving remaining segments unclosed and causing memory leaks when
downloads stalled or failed.

Changes:
- Clear() now continues closing all segments even if some return errors
- Collects all errors and returns them joined using errors.Join()
- Added comprehensive test coverage for Clear() edge cases

This fix addresses the memory leak root cause analysis findings where
stuck download goroutines could cause unbounded memory growth to 4+ GB.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant