Open OmerNinburg-RecoLabs opened 7 months ago
Hi @koltyakov , I would appreciate you considering Merging this PR. If you would like any changes in the PR - please comment so I will know.
Hi @OmerNinburg-RecoLabs ,
Thank you for an improvement.
I'm still thinking what to do with it. Please give me more time.
The reason I can't merge it now is that it introduces braking changes.
For the #2, currently, you can pass context to any hierarchy for a group or an individual call. Yet, throug .Conf method - such a mechanism was done for avoiding braking changes.
Context for GetAuth is a bit more tricky, yet maybe little consumers use it directly, so the interface braking change effect is not huge.
Anyways, I'm thinking how to resolve it.
Out of interest, are you facing an actual need in request cancelation or this is a theoretical thing?
Hi @koltyakov ,
This is not theoretical - in my use case I have an http middleware that writes all the raw http response to kafka.
This middleware uses some values that are injected to the ctx via the context.WithValue
function.
Due to the fact the GetAuth
function does not get the initiating api call ctx, my middleware is failing.
After thinking about it, I understood the best option for me is passing the ctx
as I do not want my middleware to actively know the originator of the http request.
Regarding the ctx
in the API config - I used to use it but I think it's a weird way to pass the ctx
and it is not aligned to the common use of ctx
in other pkgs (including the go core) - nevertheless, this is more syntactic sugar so I don't mind this feature being discarded
This PR has 2 main goals
GetAuth
functions - this is needed as currently theGetAuth
functions are running with the default context.Background ctx.