introduce global anomalies, build queue length, + manual via CLI

[syphar]

( updated description).

introduce "abnormality" to warn users about currently active issues.

Sources are (first version):

1. automatic for a too long queue
2. manual abnormaly in the database for the rest.

This is not for notifications, but only this kind of system status information. Notifications / alerts will be cached in the same WarningsCache, passed into the templates the same way, but shown via popup & discardable.

We cache the value for 5 minutes, so we won't have too many added database queries.

It will look like this, with multiple abnormalities:

We also have the added detail status page with more explanation.

the queue warning is additionally shown on the queue page

The audit error is fixed in #3295

[GuillaumeGomez]

I think you're trying to fix two different problems here:

1. docs.rs issues
2. docs.rs changes

The first one needs to be there as long as the issue(s) are there. The second one being a notice, it should be discard-able by the user and attract attention a lot more. So your PR fits well for 1., but doesn't for 2. imo. 2. should most likely be a static element floating over the content.

What do you think?

[syphar]

I admit I didn't think much further than just making the old feature not hardcoded, so we can start showing something somewhere.

I don't think I can build either of the other approaches in the next week, but hopefully some time after that, depending on many other factors.

[syphar]

I think you're trying to fix two different problems here:

1. docs.rs issues

2. docs.rs changes

The first one needs to be there as long as the issue(s) are there. The second one being a notice, it should be discard-able by the user and attract attention a lot more. So your PR fits well for 1., but doesn't for 2. imo. 2. should most likely be a static element floating over the content.

What do you think?

Right now I don't have an opinion on that (too tired / sick), how does crates.io do it?

Generally what you propose feels like it makes sense.

[syphar]

general thought:

with my dayjob problems right now, I don't think I can spend time on any of the proposed other things in the next week or two (except when I'm lucky, not sure).

so I'm asking myself if we should use this first to make people aware of the new default-target change first?

[GuillaumeGomez]

I can take over this PR and implement the missing parts if you want?

[syphar]

I can take over this PR and implement the missing parts if you want?

thanks for the offer!

My hunch is that you're right generally, but I want to think it through first when I'm a little better.

[syphar]

( will set the compiled-in warning in a separate PR for the current change only)

[GuillaumeGomez]

Sounds good to me. :)

[syphar]

@GuillaumeGomez I had another idea about multiple alerts, the separate page looked so empty with the information that was there..

what do you think?

It would collapse (so no dropdown) when there is only one alert.

Also now there is an example how the webserver now collects metrics from the builder-lib.

( not sure if I was too much into it and overengineered 😅 )

[GuillaumeGomez]

Well, I was kinda hoping to provide more information for each anomaly on the page. 😆

Like since how long it's happening, what's the impact to users, etc.

[syphar]

Well, I was kinda hoping to provide more information for each anomaly on the page. 😆

Like since how long it's happening, what's the impact to users, etc.

Want to add a commit how you would imagine it?

[GuillaumeGomez]

I can try. :)

[syphar]

I just rebased to fix the conflicts, will leave it alone now @GuillaumeGomez

[GuillaumeGomez]

I added the draft for the status page of docs.rs. It looks like this:

[syphar]

valid points, good idea, we can do that.

I assume that we merge the Abnormality and GlobalAlert things?

the abnormality only has the explanation & start-time on top?

[GuillaumeGomez]

GlobalAlert is different: it's like the one you can see on crates.io currently. It's supposed to have a start and an end date so we know when to render it to users.

[syphar]

will finish up this PR and ping you for the final review.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.