Guillaume Juge 28f71e727a fix(dns): report an OVH zone refresh failure for what it is ...

refreshZone runs after the record write has already succeeded, so a failure
there means the change exists at the provider but is not being served yet. It
was left unguarded at all six call sites, so the caller saw a bare transport
error and would reasonably read it as "nothing was applied" — while a type
change had already deleted the old record and created its replacement.

Rolling the write back would destroy correct state over a publish failure, and
re-deleting after an uncertain network error is how records get lost. The error
now says what actually happened and how it resolves: the next successful change
to the zone publishes it, or the user can refresh the zone from the OVH manager.

Guarding the helper covers upsertRecord and deleteRecord too, not just the type
change Greptile pointed at.

Reported by Greptile on #5258.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-04 20:23:43 +02:00

..

api

chore(api): add local Inngest dev server script

2026-09-01 19:11:27 -06:00

dokploy

fix(dns): report an OVH zone refresh failure for what it is

2026-09-04 20:23:43 +02:00

monitoring

fix: enhance container metrics query to support wildcard matching for container names

2026-03-08 16:16:45 -06:00

schedules

fix: pass timezone when removing repeatable schedule job

2026-09-01 01:31:59 -06:00