Not sure what would happen if I set the context to context.Background(),
but I'd have to understand the implications of it really well before I did
something against the grain like that (using context.Background() for
request-specific code).
Yeah, perhaps we'll go with the solution of reserving ti
Thinking some more about the problem, I think your solution of reserving
some of the deadline to handle the spanner log in the error case sounds
like the best answer. However it does lead to questions like, if you
reserve n seconds to log to spanner in the error path, and it takes longer
than n
What would happen if you write the error to spanner with a setting
context.Backgrond(), ie, no deadline?
On 16 August 2018 at 13:57, Robert Bartoszynski wrote:
> Thanks. Perhaps an alternative would be for me to create a child context
> with a deadline of (context - x seconds) and pass that to Ot
Thanks. Perhaps an alternative would be for me to create a child context
with a deadline of (context - x seconds) and pass that to OtherService,
with the expectation that there should be x seconds left over for the write
to spanner.
On Wed, Aug 15, 2018 at 8:10 PM Dave Cheney wrote:
>
>
> On Thu
On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote:
>
> As an example:
> Client calls MyService with a deadline of 10 seconds.
> MyService calls OtherService as part of responding. However, the call to
> OtherService times out due to the deadline in 10 seconds.
> MyService tries
As an example:
Client calls MyService with a deadline of 10 seconds.
MyService calls OtherService as part of responding. However, the call to
OtherService times out due to the deadline in 10 seconds.
MyService tries to log the error to Spanner; but it's still using that
context deadline which exp
