supabase-py
supabase-py copied to clipboard
Fix timeout
What kind of change does this PR introduce?
Fix for timeout-related issues.
According to httpx documentation setting the timeout property to None will ensure no timeout is used.
This could be useful when the user cannot estimate how long a running task should take, and improves the user experience because avoids using arbitrary values to get rid of such timeout errors.
A test to play with timeouts is included, with happy-path and expected-to-fail scenarios.
See also:
- https://github.com/encode/httpx/blob/4b85e6c3898b94e686b427afd83138c87520b479/httpx/_client.py#L81
- https://github.com/supabase-community/postgrest-py/blob/4b3a664abf2c35b7a08919ae7bf71c90f3fa9ef8/postgrest/constants.py#L6
Explicit is better than implicit.
What is the current behavior?
- https://github.com/supabase-community/supabase-py/issues/487
- https://github.com/supabase-community/supabase-py/issues/376
- https://github.com/supabase-community/supabase-py/issues/509#issuecomment-1721348841
- https://github.com/supabase-community/supabase-py/issues/510 ???
Notes
Another different potential approach can be just increasing the DEFAULT_POSTGREST_CLIENT_TIMEOUT,
a value of 5 feels too small for long-running tasks whatsoever.
JavaScript client does not have an explicit timeout by default (?), AFAIU.
Some libraries in the wild use -1 or 0 to mean no explicit timeout or a very huge number likely unreachable.
If the desired approach is to use an implicit integer, then maybe using a huge number can be considered.
Hey!
Personally, I think having None is fine. Thanks much for the tests!
Changing this to None would be a breaking change. I'd prefer if the timeout was increased instead and we push for None on the next major release.
See also: https://github.com/supabase-community/postgrest-py/pull/417#issue-2268986868
The changes for Postgrest-py should now be included in 2.4.4 that was released earlier.