fix: recreate Grafana Prometheus data source so pinned uid survives upgrades

Upgrading an existing installation to 1.10.0 left Grafana in a restart
loop: "Datasource provisioning error: data source not found". The data
source already existed with a random uid, and Grafana looks an existing
data source up by id AND uid when provisioning updates it, so pinning
uid: Prometheus could never match. Delete it by name before recreating
it; dashboards and alert rules reference the uid, so nothing is lost.

Release 1.10.1.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P9yjkBNtrs5twjnMK2cDFx

Author: kossakovsky

CHANGELOG.md

@@ -2,6 +2,11 @@
 
 ## [Unreleased]
 
+## [1.10.1] - 2026-09-02
+
+### Fixed
+- **Monitoring** - Upgrading an existing installation to 1.10.0 left Grafana in a restart loop with `Datasource provisioning error: data source not found`. The Prometheus data source already existed with a random uid, and Grafana cannot change the uid of an existing data source when provisioning pins one. The provisioning file now deletes the data source by name before recreating it with the fixed uid `Prometheus`; dashboards and alert rules reference the uid, so nothing is lost. Fresh installations were not affected.
+
 ## [1.10.0] - 2026-09-02
 
 ### Added

CLAUDE.md

@@ -190,7 +190,7 @@ This project uses [Semantic Versioning](https://semver.org/). When updating `CHA
 - **In queue mode the workflow counters and the duration histogram are emitted by `n8n` main**, which finalises every top-level execution; workers only report sub-workflow executions, node events and their own process metrics. Panels and rules therefore aggregate across instances (`sum by (...)`) and must not filter on `$instance`
 - Scrape targets are not static: `generate_n8n_workers.sh` writes `prometheus/targets/n8n.json` (gitignored) with the `n8n:5678` main target and one `n8n-worker-N:5678` per worker, each group carrying its `job` label, and `prometheus.yml` reads it via `file_sd_configs`. The generator runs unconditionally from `05_configure_services.sh` and removes the file when the n8n profile is inactive, so a monitoring-only install has no n8n targets and no permanently-down alert. Metrics are served on the queue-health port (`QUEUE_HEALTH_CHECK_PORT`, default 5678; 5679 is the task broker)
 - `prometheus/rules/*.yml` holds recording rules keyed on `workflow_id` (`n8n:workflow_success:increase5m`, `n8n:workflow_last_success_timestamp_seconds`); names are joined at query time from `n8n_active_workflow_info`, so renames are followed. The whole `prometheus/` directory is bind-mounted read-only to `/etc/prometheus`
-- Grafana's datasource, dashboards and alert rules are file-provisioned from `grafana/provisioning/`; contact points and notification policies are not, and no SMTP is configured. The Prometheus datasource has the fixed `uid: Prometheus` that dashboards and alert rules reference - keep them in sync. Use `$__rate_interval`, never a fixed range window, in range queries
+- Grafana's datasource, dashboards and alert rules are file-provisioned from `grafana/provisioning/`; contact points and notification policies are not, and no SMTP is configured. The Prometheus datasource has the fixed `uid: Prometheus` that dashboards and alert rules reference - keep them in sync. Grafana cannot change the uid of an existing datasource, so `main.yml` deletes it by name (`deleteDatasources`) and recreates it on every start; pre-1.10.0 installations had a random uid and crash-looped without this. Use `$__rate_interval`, never a fixed range window, in range queries
 - No Alertmanager: alert rules are Grafana-managed (`grafana/provisioning/alerting/n8n-workflows.yml`); a malformed file stops Grafana from starting. `make doctor` checks that Grafana/Prometheus run, that the targets file matches `N8N_WORKER_COUNT` and that Prometheus loaded the `n8n-workflows` rule group without errors
 
 ### Caddy Reverse Proxy

VERSION

@@ -1 +1 @@
-1.10.0
+1.10.1

grafana/provisioning/datasources/main.yml

@@ -1,5 +1,15 @@
 apiVersion: 1
 
+# Installations older than 1.10.0 hold a "Prometheus" data source with a random
+# uid. Grafana cannot change the uid of an existing data source (it looks the row
+# up by id AND uid, fails with "data source not found" and refuses to start), so
+# the data source is dropped by name and recreated with the fixed uid on every
+# start. Dashboards and alert rules reference the uid, not the id, so nothing is
+# lost. On a fresh install the delete is a no-op.
+deleteDatasources:
+  - name: Prometheus
+    orgId: 1
+
 datasources:
   - name: Prometheus
     uid: Prometheus