403 rate limit - error is very obscure (in stable)

[bigretromike]

Before submitting your issue, please verify the following.

• You're using the latest Stable or Daily version of Shoko Server.
• You're using the latest and correct (Stable:Stable, Daily:Daily) Web UI for the version of Shoko you're using.
• You've searched this repository (top of the page) for the issue you are reporting.

Shoko Version

5.3.3.0

Shoko Version - Daily Commit

No response

Install Type

"linux/docker"

Description

In logs/webui the "403 limit rate error" is obscure with debug information.
It would be awesome if only Response status code does not indicate success: 403 (rate limit exceeded). be shown instead of this monstrosity

Connection id "0ZNN8ZO2FTJZ6", Request id "0ZNN8ZO2FTJZ6:0000000A": An unhandled exception was thrown by the application.: System.Net.Http.HttpRequestException: Response status code does not indicate success: 403 (rate limit exceeded). at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode() at System.Net.Http.HttpClient.GetStringAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken) at Shoko.Server.Services.WebUIUpdateService.DownloadApiResponse(String endpoint, String repoName) in /usr/src/app/source/Shoko.Server/Services/WebUIUpdateService.cs:line 80 at Shoko.Server.Services.WebUIUpdateService.GetLatestVersion(ReleaseChannel channel, Boolean force, Boolean allowIncompatible) in /usr/src/app/source/Shoko.Server/Services/WebUIUpdateService.cs:line 319 at Shoko.Server.API.v3.Controllers.WebUIController.LatestWebUIVersion(ReleaseChannel channel, Boolean force, Boolean allowIncompatible) in /usr/src/app/source/Shoko.Server/API/v3/Controllers/WebUIController.cs:line 455 at lambda_method639(Closure, Object, Object[]) at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.SyncObjectResultExecutor.Execute(ActionContext actionContext, IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync() at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|25_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope) at Microsoft.AspNetCore.Builder.RouterMiddleware.Invoke(HttpContext httpContext) at Sentry.AspNetCore.SentryTracingMiddleware.InvokeAsync(HttpContext context) at Sentry.AspNetCore.SentryTracingMiddleware.InvokeAsync(HttpContext context) at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context) at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext) at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider) at Shoko.Server.API.APIExtensions.<>c.<<UseAPI>b__5_0>d.MoveNext() in /usr/src/app/source/Shoko.Server/API/APIExtensions.cs:line 342 --- End of stack trace from previous location --- at Sentry.AspNetCore.SentryMiddleware.InvokeAsync(HttpContext context, RequestDelegate next) at Sentry.AspNetCore.SentryMiddleware.InvokeAsync(HttpContext context, RequestDelegate next) at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)

Steps to Reproduce

get banned with few series on initial setup.
see webui log/docker log

Log File

Screenshots

No response

[revam]

That upstream error is for the rate limiting done by the GitHub API which is used by stable to check the version. Daily uses it's own manifest file instead of using the GH API, so it's much less likely to get hit by such an error. Also, the web ui will see a 502 (Bad Gateway) (iirc, otherwise it's just a plain 500) response. The snippet you sent should only be visible in the server log.

[bigretromike]

The snippet you sent should only be visible in the server log.
I copy-paste it from webui (probably because webui reads server log file?)

Also, thank for pointing out that its for gh (I didnt read that mambo-jumbo but WebUIUpdateService.cs points in that direction)

Still it would be super helpful if this was cutdown and replace with human-redacted error message ;-)

[revam]

Daily uses it's own manifest file instead of using the GH API, so it's much less likely to get hit by such an error.

I'll quote myself, and add some more info; "less likely to get hit by such an error" here means "a 0% chance of that particular error occurring," since it's not using the GH API at all, only their file host, among other differences between stable and daily.

Still it would be super helpful if this was cutdown and replace with human-redacted error message ;-)

I don't know what a "human-redacted error message" is, but any messaging in the UI would be left to the WebUI side. The stack trace you posted from the log (ne it live log in the WebUI or whatnot) should remain as a pure stack track, as it's there to show the stack of an error/exception and the traces of what lead to it occurring, it's not there for the average user. The average user could post it in our discord server's support channel or as an issue on this repo for us to look at.