Skip to content

Generated artefacts are never removed, and cycle-based pruning is unsafe #110

Description

@somethingwithproof

Is your feature request related to a problem? Please describe.

Nothing removes generated artefacts. plugins/gpsmap/XML accumulates one .xml, one .kml and one -top.html for every subnet prefix that has ever existed. Renumber a network and the old files stay forever, still served, still describing the old estate.

Describe the solution you'd like

Remove artefacts that are genuinely obsolete, with evidence rather than absence.

An implementation was written and then withdrawn, because keying deletion on "prefixes present in this cycle" is unsafe:

  • an empty cycle, from a database hiccup or a dead resolver, deletes everything
  • a partial resolver failure is worse and far more common: cycle N resolves 10.1.2.3 and writes 10.xml, 10.1.xml, 10.1.2.xml; cycle N+1 loses that resolver but still resolves 192.168.1.5, so the prefix list is non-empty, no empty-set guard fires, and all three 10.* files are deleted while parent pages link to 404s

Absence from one cycle is not evidence of obsolescence. Something time-based is needed: delete only artefacts whose mtime is older than several poller intervals, so a subnet has to be missing consistently before its files go.

Describe alternatives you've considered

Counting resolution failures and skipping the sweep when any occurred. Simpler, but on a large estate some name almost always fails, so the sweep would rarely run.

A manual "clean up stale map files" action. Safe, and it puts the decision with the operator who knows the network was renumbered.

Additional context

Requires the poller diagnostics in #97 to distinguish "query failed" from "no mapped Devices", which are currently the same signal.

Metadata

Metadata

Labels

bugSomething isn't workingenhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions