GithubHelp home page GithubHelp logo

Comments (3)

brendanheywood avatar brendanheywood commented on September 22, 2024

had a chat with @matthewhilton and I think the cleanest design is that the overrides only ever happen at the check level which will make the logic of handling the overrides much easier. But this kinda moves the problem in that we still have some checks like 'are there any slow tasks' which are really checking a whole bunch of things and when they fail it could fail on any type of task.

So the solution I have in mind for this is that various checks (only the ones in heartbeat) actually conditionally declare multiple checks for each class of issue. So lets say that a site is green and there is 100 tasks and they are all good, then there is 1 check and it is green.

Now lets say that 3 types of task start to fail, then we will see the one original check which says 97 tasks are good, and then 3 new extra checks which say 'task foo is broken', 'task bar is broken', 'task blah is broken' and now we can address each of them in turn individually. In other words the main check will never actually fail it will only spawn failing tasks. It also means the logic of looking for failing tasks needs be move back into lib.php (or called from there) rather than inside the result object. A little weird but I think its ok for this situation as its a fast query and it is only moving the perf hit to a bit earlier.

from moodle-tool_heartbeat.

brendanheywood avatar brendanheywood commented on September 22, 2024

One more thing, if we mark a failing check as muted for a month, and then after one month that check is actually resolved, either the check is no longer declared or the check is declared and is passing, then I think we should explicitly mark the override as having been resolved. If the check is still failing then it is shown as overdue and it keeps alerting and someone will probably extend it again and / or resolve it properly. We want a full audit trail of who added overrides if the same check fails intermittently over time.

from moodle-tool_heartbeat.

owenherbert avatar owenherbert commented on September 22, 2024

I've created a consolidated README.md file on what these changes would look like, let's discuss it on Monday.

from moodle-tool_heartbeat.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.