-
Notifications
You must be signed in to change notification settings - Fork 347
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
Rpc doesn't account for metadata #1028
Comments
I think most users have used metadata on the server, i.e. to accept incoming data like auth headers. Also I think that its the client If you needed to pass per-callsite metadata into a Do you need to do that? Or can you follow the ^ pattern and have the |
We’re trying to thread trace ids through, which gets tricky I think. Let me think more about workaroundsOn Apr 13, 2024, at 12:44 PM, Stephen Haberman ***@***.***> wrote:
I think most users have used metadata on the server, i.e. to accept incoming data like auth headers.
Also I think that its the client Rpc implementations that put this metadata on the wire, and not the individual call sites that are calling SomeService.someMethod.
If you needed to pass per-callsite metadata into a await someService.someMethod(...) call, and have that passed through the Rpc interface, then yeah we do not support that atm.
Do you need to do that? Or can you follow the ^ pattern and have the Rpc implementation generically put the same auth/user metadata on the wire for all calls?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
There's an option to include a metadata?: Metadata arg, but only under certain providers. There's also no option to receive Metadata from the response.
This seems like a pretty wide-ranging potential change. Have people run into this problem before?
The text was updated successfully, but these errors were encountered: