Problem/Motivation

The report page's "Over time" chart promises open finding totals at each check-up — but it plots every stored run, including category-filtered (partial) runs, as if it were a full measurement of the site. A partial run only collects one category's checks, so every other category records zero for that run: after a couple of site-doctor:check system invocations, the notices line dives from its real value to 0 and jumps back at the next full check-up. The dip is an artifact of run scope, not site history.

The results store itself is unaffected — per-check resolution authority keeps finding lifecycles honest across partial runs. Only the chart's aggregate projection misreads the data.

Steps to reproduce

  1. Run a few full check-ups on a site with findings in more than one category.
  2. Run drush site-doctor:check system (any single category) once or twice.
  3. Open the report page: the other categories' severity lines drop to zero at those runs, then recover.

Proposed resolution

The severity trend (chart and its collapsed data table) plots complete runs only (site_doctor_run.status = 'complete'), and the chart's help text says so ("full check-ups only — category-filtered runs are not plotted").

Deliberate consequence worth agreeing to: a run that is partial because a check crashed is also excluded. That is arguably correct — its totals are incomplete too — and a crashing check is already loud everywhere else (operational-failure exit code, failure rows in history). A site whose every run is partial charts nothing, which is honest.

Remaining tasks

  • Restrict the trend query to complete runs; update the help text.
  • Kernel test: a partial run between two full runs does not produce a data point.

User interface changes

The "Over time" chart stops showing artificial dips; one sentence of help text added.

API changes

None.

Data model changes

None — a query-level filter over existing tables.

Issue fork site_doctor-3608752

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

amangrover90 created an issue. See original summary.

amangrover90 opened merge request !10

amangrover90’s picture

amangrover90 commented

MR !10 is up. During review the scope grew beyond the posted summary — same chart-honesty theme, noting the additions for the record:

  • Partial runs excluded from the trend (the posted bug): complete runs only, disclosed in the help text.
  • Severity scope filter now applies to the chart and its data table — the filters at the top of the page promise to apply to everything below them, and the chart was the one section ignoring the severity choice. Severities hidden by the filter are absent entirely, not listed as "none".
  • Hover tooltips on every data point (SVG-native <title> elements, no JavaScript). This surfaced a paint-order bug: a later series' area fill sat on top of earlier series' dots and swallowed their hover targets — dots now paint after all fills.
  • Bucket sampling for dense data: long histories sample to the last complete check-up per bucket (state sampling, never averaging). Bucket size follows the data's actual span — span ≤7 days plots every run, ≤90 days daily, beyond weekly — deliberately not the selected period, so a young site's two days of runs plot in full even on the 365-day view instead of collapsing to a blank chart. Sampling is disclosed in the help text, and the "no warnings" caption then honestly says "at the plotted check-ups".

Kernel tests cover the partial-run exclusion and the last-run-per-bucket sampling.

  • amangrover90 committed b9fee314 on 1.x 
    Resolves #3608752: Trend chart plots partial runs as full data points
amangrover90’s picture

amangrover90 commented
Status: Active » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.