[andre8244]

📋 Description

The dashboard systems card could count inactive systems that the systems list, filtered by inactive, did not show: they appeared as pending, or not at all. GET /systems/totals derived the status from the heartbeat age, while GET /systems?status= filters on the systems.status column that the collect heartbeat monitor maintains, and the two disagree in several cases.

The totals now count the status column with the same suspended exclusion as the list filter, so each count equals the filtered systems list. The dashboard card now shows only the total: its status badges excluded suspended and unregistered systems, as the lists do, so they no longer added up to the total. Restoring a soft-deleted system that has reported before now sets it inactive instead of unknown: the monitor only promotes unknown on a fresh heartbeat, so a silent restored system stayed pending forever.

• Cases that disagreed before: suspended systems, unregistered ones with a stale heartbeat, the 15 vs 20 minute timeouts of backend and collect, and restored systems.
• The timeout query parameter and the timeout_minutes response field of /systems/totals are removed, as they no longer mean anything. The frontend never sent the parameter.
• Migration 060 (data only) moves the systems already restored as unknown with a heartbeat row to inactive. Those, like any silent restored system from now on, will raise LinkFailed. It is numbered 060 because 052-059 are taken on feature/support-service.
• The unused copy of the totals query in entities/local_systems.go is removed.

Related Issue: None

🚀 Testing Environment

To trigger a fresh deployment of all services in the PR preview environment, comment:

update deploy

Automatic PR environments:

• Proxy: https://my-proxy-qa-pr-259.onrender.com

How to test:

1. The dashboard systems card shows only the total, which matches the unfiltered systems list.
2. Call GET /systems/totals and compare active, inactive and unknown with the systems list filtered by each status: they match, also after suspending an inactive system.
3. Delete and restore a system that has sent heartbeats: it comes back inactive, not pending.

✅ Merge Checklist

Code Quality:

• 
• 
• 
• 

Builds:

• 
• 
• 
• 

[edospadoni]

Two notes before merging, neither blocking.

1. Migration 060 will fire LinkFailed for the systems it moves

The systems moved to inactive enter the linkfailed_monitor query, so each one raises a LinkFailed alert, and notifications go out on the first cycle after the migration. I checked prod (read-only):

SELECT count(*) FROM systems s
JOIN system_heartbeats h ON h.system_id = s.id
WHERE s.status = 'unknown' AND s.deleted_at IS NULL AND s.unregistered_at IS NULL;

→ 1 system, not suspended, silent since 2026-10-29 10:40 UTC. So a single LinkFailed alert, which is the correct outcome. Nothing to warn partners about.

2. total is no longer the sum of the badges

active/inactive/unknown now exclude suspended systems, and unregistered ones fall in none of the three, but both still count in total. On the dashboard card total ≠ active + inactive + unknown, while before the suspended ones landed in one of the badges. This is consistent with the list (each badge matches its filter), but a user may read it as a wrong count. Fine to accept as is; just flagging it in case we want suspended/unregistered badges later.

Also: from now on the next migrations on main start at 061.

[github-actions]

🚨 Breaking my.nethesis.it API change detected

Preview documentation

Structural change details

Modified (1)

• GET /systems/totals
  • Response modified: 200
    • Content type modified: application/json
      • Property modified: data
        • [Breaking] Property removed: timeout_minutes
          • Removing a resource is always breaking unless it was deprecated before [Breaking]
  • [Breaking] Query parameter removed: timeout
    • Removing a resource is always breaking unless it was deprecated before [Breaking]

Powered by Bump.sh

[andre8244]

2. total is no longer the sum of the badges

active/inactive/unknown now exclude suspended systems, and unregistered ones fall in none of the three, but both still count in total. On the dashboard card total ≠ active + inactive + unknown, while before the suspended ones landed in one of the badges. This is consistent with the list (each badge matches its filter), but a user may read it as a wrong count. Fine to accept as is; just flagging it in case we want suspended/unregistered badges later.

Solved by removing all badges from the Systems card