mirror of
https://github.com/Dokploy/dokploy.git
synced 2026-09-12 19:51:00 +05:00
2311f346d4
restoreRecord had the restore POST and its zone refresh inside one catch. That was harmless while refreshZone swallowed failures, but the previous commit made it throw, which brought a new case into that catch: the restore succeeds and only the publication fails. The message then told the user the record "has been deleted" and to recreate it by hand. It exists at OVH, just unpublished, so following that advice duplicates it as soon as the zone is refreshed. The two failures are now reported separately. A failed POST still means the record is really gone and prints what to recreate. A failed refresh after a successful restore says the record is back but not served yet, and explicitly says not to recreate it. Either way the original replacement error is kept, so the user still learns why the type change failed. Reported by Greptile on #5258. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| api | ||
| dokploy | ||
| monitoring | ||
| schedules | ||