Stitching resillience

[PendingChanges]

We are using schema stitching with HotChocolate 12 with many external services and we are trying to make HTTP clients resillient (like said in the v10 doc of HotChocolate : https://chillicream.com/docs/hotchocolate/v10/stitching/#making-http-clients-resilient).

Today, if one of the service referenced by the gateway is unavailable, the gateway sdl (and the query/mutations calls) are all broken.
I'm trying some things with Polly by wrapping up Retry and Fallback policies : When a service is in error 3 times in a row, I have a fallback policy to return something which is not breaking all the gateway.
I tried returning a 200 status when fallback is reached but it still break everything.

What can I return in my fallback policy to make the gateway understand that one of the services is unavailable and don't break everything?

[michaelstaib]

Its a bit more complex than just putting polly in. If you want the stitching to be resilient you can use our redis stitching provider where we store the last valid schemas on redis. Whenever one component restarts and we cannot reach one of the downstream services we will refer to the redis cache.

[DuCNiKo]

Hi Michael,
I'm working with Remi and I'll try to explain better the situation.

We are currently stitching schemas defined on multiple micro services on which we have no leverage... Some on them are developed with HotChocolate when others are Java Spingboot applications using Netflix DGS for GraphQL.

As of today, I've answered Remi's concerns with this:

• I've used the AddRemoteSchema extension method with the loadSchema function. On this function, I've copied pasted the loadSchema method used on line 89 of the StitchingRequestExecutorExtensions
• When an exception occurs on the HttpClient call, I return a specific RemoteSchemaDefinition mostly empty with the schéma name and the error as query (not the best idea, I know but I'll explain later why)

Now our issue is more: how if an other team create something that the stitcher does not understand, I still can have a stitching application up and running, with all the schéma we understand queryable and the one that does not work down.

To be more specific, our Java developers use the BigDecimal scalar type that is twice the size of the dot et decimal... and tomorrow, I'm not sure that they will not deploy their services with other surprises...

Now a more precise question:

• from what I've understood, the stitcher perform an HttpClient query to get the remote schéma définition.
• From that definition a Schéma is created and merged within the stitcher local schéma
• Today the BigDecimal issue is preventing us to create the schéma from the remote schéma définition. I have not found a way to put a try\catch around the schemaBuikder.Create to return a "fake" Schéma if an error occurs
• I also have not found a way, with interceptors, to tell the pipeline: "Ok you have an error, let me log the error but use this empty schéma instead". Is there a way ?

All of this is to always have a stitching applications up and running with the most usable schéma available...

Any ideas ?

PS: sorry for the typo in the message but I'm using my phone with a French corrector...

[maxstue]

@DuCNiKo Hi I'm facing the same issue with a "BigDecimal" Scalar in a remote schema.
Did you find a solution on how to convert it or work around it ?

[PendingChanges]

@DuCNiKo Hi I'm facing the same issue with a "BigDecimal" Scalar in a remote schema.
Did you find a solution on how to convert it or work around it ?

Hello. We used a workaround in our context. As the BigDecimal type is only used through graphql to display amounts on the front application, we created a scalar "BigDecimalString" which is actually a string and declared it on the gateway and in all Java microservices.
With this scalar we now transfer amounts to front applications as string and it's not truncated anymore by the. Net gateway.