[grpc-io] Standardization of rich error reporting via google.rpc.Status

[Chris Toomey]

Per this  SO post and some 
messages in this group, there looks to be agreement on and progress towards 
enabling richer gRPC error reporting via google.rpc.Status 
 as a replacement 
for io.grpc.Status 

.

But nowhere on the gRPC website  including the error 
handling  page is this mentioned, which 
seems a major omission -- it takes a fair bit of googling to discover this. 
For the sake of other developers looking to adopt gRPC and needing to 
support richer error reporting, will somebody update that page to talk 
about this? Similarly, the use of the grpc-status-details-bin 
header/metadata key should be added to the gRPC over HTTP2 
 spec. 
(flagged as "experimental" or something if needed).

We're using akka-grpc and until I asked about supporting google.rpc.Status 
  yesterday it 
wasn't even on their radar.

It's really hard to tell where this stands in terms of official library 
support too. It'd be really helpful to list/track official library support 
status for this on the error handling  page 
or somewhere else on the gRPC website .

Speaking of library support status, is this currently available, or being 
worked on, for the following languages?

Java
JS (grpc-web)
Objective C

thanks,
Chris

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/6c1642af-23ce-48ab-9bf0-260897a6ca3d%40googlegroups.com.

Re: [grpc-io] Python gRPC (client) has support for async/await, or still use threading

['Lidi Zheng' via grpc.io]

AsyncIO support is in the top of the road map of gRPC Python team. The past
discussion can be found here -> https://github.com/grpc/grpc/issues/6046.
Currently, gRPC Python only support multi-threading, and forking on
client-side.

*From: *
*Date: *Thu, May 9, 2019 at 2:47 AM
*To: *grpc.io

As the title suggests, I can't determine whether async/await support has
> made it into Python gRPC (client) yet.
>
> I have seen numerous other threads about this (no pun intended), but
> nothing concrete as to what is supported.
>
> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/8f425c3e-dd69-4937-ac5a-25b539116f3a%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAMC1%3DjfTSmoqu2o4K6%2BZP1Acjfqz42G4DRSw92OnkkyCZ-%2Bt_A%40mail.gmail.com.

[grpc-io] Re: [C#] Mocking server side streaming calls (ClientStream, ServerStream, Bidi)

[Joseph Vaughan]

 

Hi Christopher, 

 

Thank you for your response, I had a feeling that this is the way that it 
should be approached. In my case the RPC is fairly straight forward, but 
I’d still like it to be testable, so perhaps using DataFlow blocks as you 
have is suitable. I’ll look into it thanks.


On Tuesday, 7 May 2019 22:35:52 UTC+1, Christopher Warrington - MSFT wrote:
>
> On Tuesday, May 7, 2019 at 1:57:34 AM UTC-7, Joseph Vaughan wrote:
>
> > Does anyone have any good solutions for substituting in the
> > IServerStreamWriter, IClientStreamWriter, IAsyncStreamReader types, 
> either
> > under a mock framework or with test stubs?
>
> In my team's code base, we've divorced the business logic from the gRPC
> handler implementation by using DataFlow [1] blocks. The business logic
> doesn't even contain a reference to the gRPC assemblies at all. It does use
> Proto messages. This makes the business logic easily unit testable.
>
> We have small adapters from the gRPC interfaces to Dataflow blocks. The
> service handlers use these adapters to bridge from IServerStreamWriter &
> friends to the business logic's input/output types. These adapters get
> tested in our server integration tests.
>
> We have four different projects of interest here:
>
> * core (class library): business logic
> * core-tests (unit tests): tests for code in core
> * service (executable): reads config, starts gRPC service, gRPC to business
>   logic adapter (service handlers), Dataflow blocks adapter
> * service-tests (integration tests): stands up full service using 
> single-box
>   config and exercises it
>
> [1]: 
> https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/dataflow-task-parallel-library
>
> --
> Christopher Warrington
> Microsoft Corp.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/33f00e7d-395c-489c-97fe-06a0503abd97%40googlegroups.com.

[grpc-io] Python gRPC (client) has support for async/await, or still use threading

[will8clark]

As the title suggests, I can't determine whether async/await support has 
made it into Python gRPC (client) yet. 

I have seen numerous other threads about this (no pun intended), but 
nothing concrete as to what is supported.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/8f425c3e-dd69-4937-ac5a-25b539116f3a%40googlegroups.com.