fix: copy client options instead of deepcopy #1130
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Deepcopy fails to copy thread objects, like I can't implement a config class that has a client instance of Supabase as a attribute
What kind of change does this PR introduce?
Bug fix for this issue: #1129
What is the current behavior?
SyncClient.init receives a
option
argument that could be a ClientOptions, this ClientOptions instance can also have specific implementations for storage.Then, init tries to copy the options attribute to it's instance, since options.headers is a dictionary, a deepcopy garantees recursively that headers is copied too. But this drives to another kind's of unexpected erros since we don't have control of the implementation of any ClientOptions derived class.
The bug is:
You can reproduce my scenario by checking this gist:
https://gist.github.com/rild-software/ad23c35c49f64508cf2cc530e72b703f
What is the new behavior?
init method only copy the contents (not recurively) and then explicitly copy the headers.