-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/optional last response preserving #146
Feature/optional last response preserving #146
Conversation
@iansparks @glow-mdsol |
Looks good to me. |
@jmann-mdsol @glow-mdsol @isparks-tg @isparks-tg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok with me.
@rosh-n-ix can approve but not my place to merge. Defer to someone at Medidata, @glow-mdsol ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Let me do a quick PR to resolve the issue with CI, then we can merge that and get this pulled in |
Ok, should be good to update from develop and then we can get this released |
89d85a1
to
85726f0
Compare
@glow-mdsol done! Thank you |
Issue:
When fetching clinical data, there are cases where files exceeding 2 GB are being transferred. Currently, the client always retains the response object in a class property, which results in doubling the memory usage.
Solution:
In this pull request, I’ve made the preservation of the response object optional. This change reduces memory consumption by preventing the client from unnecessarily holding the response object in memory, especially for large file transfers.
Also: Error catching was refactored, test added, lib version updated