Skip to content

Document upload with Stream support#143

Open
lyubobg wants to merge 5 commits intobraintree:masterfrom
lyubobg:docUploadMemoryStreamSupport
Open

Document upload with Stream support#143
lyubobg wants to merge 5 commits intobraintree:masterfrom
lyubobg:docUploadMemoryStreamSupport

Conversation

@lyubobg
Copy link

@lyubobg lyubobg commented Feb 24, 2026

Summary

Checklist

  • Added changelog entry
  • Ran unit tests (Check the README for instructions)
  • I alphabetized all attributes, parameters, and methods by name in any class file I changed
  • I have linked the JIRA ticket in the summary section
  • I have reviewed the JIRA ticket to ensure all AC's are met
  • x ] I understand that unless this is a Draft PR or has a DO NOT MERGE label, this PR is considered to be in a deploy ready state and can be deployed if merged to main

lahtarov and others added 5 commits February 23, 2026 18:54
Extend DocumentUpload.Create() and CreateAsync() to accept any Stream
type (not just FileStream), enabling uploads from MemoryStream and
other stream sources. This is useful for scenarios where files are
already loaded in memory or come from non-file sources.

Changes:
- Add FileStream and FileName properties to DocumentUploadRequest
- Implement new overloads for PostMultipart/PostMultipartAsync accepting
  Stream + fileName parameters
- Add StreamWithName internal class to BraintreeService for stream handling
- Update HttpService.GetMultipartFormData to handle StreamWithName via
  reflection
- Modify validation message from "File must not be null" to
  "Either FileStream or File must not be null"
- Add comprehensive unit and integration tests for Stream functionality

When both File and FileStream are provided, FileStream takes precedence.

Tests include:
- Successful uploads with MemoryStream (sync and async)
- Priority validation (FileStream over File)
- Error handling for unsupported file types via Stream
- Validation for null parameters
The previous name 'FileStream' was confusing because:
- FileStream is a .NET system type
- Having a property named FileStream alongside File property was ambiguous

Renamed to ContentStream which more clearly indicates:
- It accepts any Stream type (MemoryStream, FileStream, etc.)
- It represents the content to upload, not specifically a file stream

Changes:
- Rename DocumentUploadRequest.FileStream to ContentStream
- Update DocumentUploadGateway.cs to use ContentStream
- Update validation message to reference ContentStream
- Update all unit and integration tests

All tests passing.
When handling StreamWithName, reset the stream position to 0 before
copying if the stream is seekable. This prevents uploading empty or
partial files when the caller passes a stream that has already been
read from.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Add changelog entry describing Stream support feature
- Alphabetize properties in DocumentUploadRequest for consistency with
  Braintree SDK conventions (ContentStream, DocumentKind, File, FileName)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Refactored HttpService to use direct type checking and property access
instead of reflection-based approach:

- Added `using static Braintree.BraintreeService` for StreamWithName access
- Replaced `param.Value?.GetType().Name == "StreamWithName"` with pattern
  matching: `param.Value is StreamWithName streamToUpload`
- Removed reflection calls (GetProperty, GetValue) in favor of direct
  property access to `.Stream` and `.Name`
- Improved performance by eliminating runtime reflection overhead
- Enhanced type safety with compile-time checking
- Cleaner, more readable code

No functional changes - all tests passing.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@volodymyrchernyshev
Copy link

lyubobg, thank you for providing this PR. Just to let you know that this PR is prioritized for the next server SDK release.

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.

3 participants