[GH-ISSUE #441] Beszel monitoring issue when server deleted and re-added with same name (fingerprint edge case) #287

New issue

Closed

opened 2026-03-03 11:14:31 +03:00 by kerem · 0 comments

kerem commented

2026-03-03 11:14:31 +03:00

Owner

Originally created by @manikanta9176 on GitHub (Sep 11, 2025).
Original GitHub issue: https://github.com/dflow-sh/dflow/issues/441

Originally assigned to: @manikanta9176 on GitHub.

Description

There is an issue in beszel monitoring where, if a server is deleted and then a new one is added with the same name, monitoring fails or behaves unexpectedly. This appears to be an edge case related to the beszel fingerprint mechanism, which may not properly distinguish between the old and new servers with the same name.

Steps to Reproduce

Delete an existing server from monitoring.
Add a new server with the same name as the deleted one.
Observe beszel monitoring behavior.

Expected Behavior

Beszel should correctly monitor the new server, regardless of name reuse, without any conflict or stale data from the previous fingerprint.

Actual Behavior

Monitoring shows inconsistent or erroneous results, likely due to fingerprint collision or stale identification.

Tasks

Investigate and resolve the fingerprint issue when servers are deleted and re-added with the same name.
Check for other related edge cases in beszel monitoring and resolve them.
Add tests for these scenarios to prevent regressions.

Additional Context

This may require refactoring how fingerprints are generated or associated with servers.

Originally created by @manikanta9176 on GitHub (Sep 11, 2025). Original GitHub issue: https://github.com/dflow-sh/dflow/issues/441 Originally assigned to: @manikanta9176 on GitHub. ### Description There is an issue in beszel monitoring where, if a server is deleted and then a new one is added with the same name, monitoring fails or behaves unexpectedly. This appears to be an edge case related to the beszel fingerprint mechanism, which may not properly distinguish between the old and new servers with the same name. ### Steps to Reproduce 1. Delete an existing server from monitoring. 2. Add a new server with the same name as the deleted one. 3. Observe beszel monitoring behavior. ### Expected Behavior Beszel should correctly monitor the new server, regardless of name reuse, without any conflict or stale data from the previous fingerprint. ### Actual Behavior Monitoring shows inconsistent or erroneous results, likely due to fingerprint collision or stale identification. ### Tasks - Investigate and resolve the fingerprint issue when servers are deleted and re-added with the same name. - Check for other related edge cases in beszel monitoring and resolve them. - Add tests for these scenarios to prevent regressions. ### Additional Context This may require refactoring how fingerprints are generated or associated with servers.