Fixes#5279. The Domains table (and grid) view mounts one AddDomain
instance per row for the edit action. Its 4 queries (domain.one,
application.one/compose.one, domain.canGenerateTraefikMeDomains,
compose.loadServices) ran unconditionally on mount instead of only
when the edit dialog is open, so any table interaction that causes a
re-render (typing in the host filter, sorting, toggling columns) fired
all 4 queries for every domain row again.
#5257 merged, so canary now carries the Infomaniak provider and its
0191_cool_christian_walker. This branch's 0191_elite_ultragirl collided on the
number, and the conflicts were the usual "infomaniak and ovh added at the same
spot" across the enum, the config union, the client registry, SENSITIVE_FIELDS,
both providerLabels maps, the icons and the provider form — all resolved by
keeping both.
Regenerated as 0192_light_lake with a current timestamp rather than renaming the
file, so drizzle still applies it on a database that has already run canary's
0191.
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>
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>
canary landed its own 0190 (0190_nappy_anita_blake), which collides with this
branch's 0190_even_mastermind. Renaming would not have been enough: drizzle
applies migrations by comparing timestamps against the last applied one, so this
branch's older `when` would have been silently skipped on any deployment that
had already run canary's 0190, leaving the enum without its new value.
Regenerated as 0191_elite_ultragirl with a current timestamp.
canary landed its own 0190 (0190_nappy_anita_blake), which collides with this
branch's 0190_perpetual_red_skull. Renaming would not have been enough: drizzle
applies migrations by comparing timestamps against the last applied one, so this
branch's older `when` would have been silently skipped on any deployment that
had already run canary's 0190, leaving the enum without its new value.
Regenerated as 0191_cool_christian_walker with a current timestamp.
- Onboarding wizard (Welcome -> Plan -> Project -> Server -> Deploy ->
Complete), shown once to an org owner with zero projects and no active
plan/trial; skippable per step or entirely
- Billing page shows the org's current plan, and a no-card 14-day trial
card when eligible
- Post-checkout "Welcome to Dokploy Cloud" modal simplified to reuse the
onboarding wizard's own project/server/deploy steps behind a modal
instead of its previous standalone 6-step flow, using the app's regular
typography instead of the wizard's display serif
- Onboarding wizard validates a persisted project still exists before
resuming a stale session, and the dashboard layout no longer gets stuck
redirecting to /dashboard/home once the local onboarding-active flag
goes stale mid-session
- onboardingCompletedAt column on user, with a backfill so existing users
aren't shown the wizard
- pnpm reset-onboarding dev script to reset a test account's onboarding
state end to end
- Sanitize customCss in _document.tsx to prevent XSS breakouts by stripping </style> tags.
- Remove SSR favicon fetching to prevent SSRF and internal network scanning, falling back to client-side fetching.
Mauricio Siu