Problem with Updates Indicator on the Host Node

[nikcomp]

Describe the bug

After running a Proxmox node update from PegaProx with reboot enabled, the update completes successfully, the host comes back online, maintenance mode is exited, and the logs show [OK] Node update completed, but the left sidebar continues to show the node as (Updating).

The node details page shows the host is online and has 0 updates, so this appears to be a stale PegaProx update-state/UI state issue rather than an active Proxmox update.

From source inspection, it looks like the sidebar marks a node as updating based on whether the node exists in self.nodes_updating:

is_updating = node_name in self.nodes_updating

The update-start path adds the node to self.nodes_updating, but after successful completion the node does not appear to be removed from that dictionary. The logs show the update completes successfully, but the sidebar still treats the node as updating.

Restarting pegaprox.service clears the stale (Updating) badge, but restarting PegaProx after every node update is not a reasonable operational workaround.

Steps to Reproduce

1. Put a Proxmox node into maintenance mode using PegaProx.
2. Start a node update from PegaProx with reboot enabled.
3. Wait for the update to complete and for the node to come back online.
4. Confirm PegaProx logs show the node update completed.
5. Check the PegaProx sidebar.

Expected behavior

After the node update completes successfully, the node should no longer show as (Updating) in the sidebar.

The update state should automatically clear once the node reaches a terminal update state such as completed or failed.

Environment

• PegaProx Version:
• Installation Method: Manual/systemd install under /opt/PegaProx
• OS: Debian Linux container
• Browser:
• Behind Reverse Proxy?
• UI?

Logs

[MAINT] Entering maintenance mode for node: proxmoxb
[MAINT] Trying native HA for proxmoxb (user=root)
[HA] Running: ssh root@<node-ip> 'ha-manager crm-command node-maintenance enable proxmoxb'
[MAINT] native HA flag set for proxmoxb
[MAINT] HA flag set for proxmoxb, now evacuating VMs ourselves
[PKG] Found 1 VMs to evacuate from proxmoxb
migrating <vm-name> (<vmid>) proxmoxb -> proxmoxc
[OK] Migration initiated for <vm-name> to proxmoxc
[OK] Maintenance mode ready for proxmoxb - all VMs evacuated
[SYNC] Starting update for node: proxmoxb (reboot: True, force: False)
Sending reboot command to proxmoxb (root=True)
Waiting for proxmoxb to come back online (timeout: 600s)...
[NODE] cluster 'Proxmox' observed 'proxmoxb' back online via /nodes aggregate — clearing breaker
[NODE] cluster 'Proxmox' node 'proxmoxb' recovered after 3 failures
[OK] proxmoxb is back online!
[HA] Running: ssh root@<node-ip> 'ha-manager crm-command node-maintenance disable proxmoxb'
[MAINT] disabled native HA maintenance for proxmoxb
[OK] Exited maintenance mode for proxmoxb
[OK] Node update completed for proxmoxb

Relevant local source behavior observed:

# Sidebar / node status logic
is_updating = node_name in self.nodes_updating

# Start update path
self.nodes_updating[node_name] = task

# Completion path logs completion, but the node appears to remain in self.nodes_updating
self.logger.info(f"[OK] Node update completed for {node_name}")

# Existing clear logic only removes it if clear_update_status() is called
def clear_update_status(self, node_name: str) -> bool:
    with self.update_lock:
        if node_name in self.nodes_updating:
            task = self.nodes_updating[node_name]
            if task.status in ['completed', 'failed']:
                del self.nodes_updating[node_name]
                return True
    return False

Screenshots

Screenshot 1: Sidebar showing proxmoxb (Updating) after the update completed.

Screenshot 2: Node details page showing the same host online with 0 updates.

Checklist

• I have searched existing issues to make sure this is not a duplicate
• I am using the latest version of PegaProx

[mkellermann97]

Nice catch — and your root-cause read was spot on. The finished task did stay in nodes_updating, and the only thing that cleared it was the node card's auto-dismiss firing the DELETE, which never runs if you're only looking at the sidebar. Fixed on Testing: the finished task now clears server-side after a short grace window (30s on success / 2min on failure, so the completed/failed banner still shows), and a leftover terminal task no longer blocks re-running an update on the same node. It'll be in the next build — give it a go and let me know if anything sticks. Thanks for the detailed report and the source dig; that made this a quick one. If PegaProx is useful to you, opencollective.com/pegaprox keeps the turnaround fast. — Marcus