How to map response of rate limit quota into exception?

[sarahhachouche1]

I want to map response of rate limit quota into exception,

app.UseSwaggerForOcelotUI(opt =>
    {
        var serverOcelot = Configuration["ServerOcelot"]; // Could be replaced by a non existing functionality https://github.com/dotnet/aspnetcore/issues/5898
        opt.PathToSwaggerGenerator = "/swagger/docs";
        opt.DownstreamSwaggerEndPointBasePath = $"{serverOcelot}/swagger/docs";
        opt.ReConfigureUpstreamSwaggerJson = AlterUpsteamSwaggeerJson;
        opt.ServerOcelot = $"{serverOcelot}";
    })
    .UseOcelot()
    .Wait();

app.Use(async (context, next) =>
{
    await next(context);

    if (context.Response.StatusCode == 429)
    {
        throw new RateLimitException("Rate limit exceed");
    }
});

But its not even reaching my Startup.cs... Any insight how to do so?

[raman-m]

Hi Sarah!

You are trying to add custom middleware into Ocelot pipeline (middleware conveyor) by this code:

app.Use(async (context, next) =>
{
    await next(context);

    if (context.Response.StatusCode == 429)
    {
        throw new RateLimitException("Rate limit exceed");
    }
});

It is a quite risky, because you don't control and you don't know the order of middleware execution.
Another problem, I can't give any advice on UseSwaggerForOcelotUI... This is beyond the responsibility of Ocelot's team.

What is the goal of your throwing of custom exception?
Do you need to catch the error on client's side?

Why not to customize Rate Limiting by options?

  "RateLimitOptions": {
    "QuotaExceededMessage": "Customize Tips!",  // custom message for clients
    "HttpStatusCode": 123,  // custom status code for clients
  }

See the docs: Rate Limiting | Ocelot Own Implementation

---

Regarding execution order of your custom middleware ...

I recommend to read the docs to understand Middleware Injection better.
This will allow you to control the order of middleware execution.
If you will inject your middleware using ASP.NET app.Use(async (context, next) => { }); then you have to check the order in debugging session! Seems it will be the last middleware, but I am not sure.

Let me know if it won't help.

[sarahhachouche1]

hi raman, I want the response to be standard problem details.

[raman-m]

When you said "standard problem details", what did you mean actually?

• ASP.NET exception report on client's side?
• Ocelot errors on client's side?

Did you read this chapter? → Error Status Codes
Because of that feature Ocelot has global exception handler which catches all exceptions and converts them to Ocelot error code.
So, why do you need exception details on client's side?

FYI

Ocelot global exception handler doesn't allow to send exception body to client's side. Ocelot reports via error codes.
So, Ocelot cannot send 5xx statuses because it crashes current Ocelot instance Docker container, so Ocelot tries to catch all unhandled exceptions and converts to something different. But Ocelot produces 5xx statuses also. See Server error responses

The better productive approach is logging some errors into Ocelot log, and adjust behavior of clients based on Ocelot error codes, or develop custom processing to gain whatever you need.