fix(volume-backups): clear retention amount when the field is emptied - #5077
fix(volume-backups): clear retention amount when the field is emptied#5077NoiceHax wants to merge 2 commits into
Conversation
Clearing "Keep Latest Backups" computed a `null` retention and then immediately mapped it back with `?? undefined` before calling the mutation. Drizzle omits `undefined` columns from the generated UPDATE, so `keepLatestCount` was never written and the previous limit kept pruning backups the user believed were retained forever. Send the explicit `null` instead, matching how the database backup form already handles the same field, and move the normalization into a small pure helper so it can be covered by a test. Closes Dokploy#4184
dosubot
Bot
added
the
size:S
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| return null; | ||
| } | ||
|
|
||
| return value ?? null; |
There was a problem hiding this comment.
When an existing limit is cleared and replaced with a non-integer value such as 3.5, the input handler leaves the parsed form value undefined while retaining the nonempty raw value. This fallback converts that state to null, silently disabling backup pruning instead of rejecting the invalid value.
Knowledge Base Used: Backups and Schedules
…ng it The number input dropped anything that was not a whole number, so a non-empty but invalid value like "3.5" left the parsed form value undefined while the raw input stayed non-empty. prepareKeepLatestCount turned that into an explicit null, which silently disabled pruning. Pass the raw value to the form so the schema rejects it and the user gets a validation message. prepareKeepLatestCount now returns undefined for that state so the update leaves the stored retention untouched.
dosubot
Bot
added
size:M
|
Fixed the invalid-input case from the review. The number input used to swallow anything that was not a whole number, so a non-empty value like 3.5 left the form value undefined and the helper turned that into an explicit null, wiping the retention limit. Now the raw value goes straight to the form, so the schema rejects it and the user sees "Must be a whole number" instead. prepareKeepLatestCount returns undefined for that state, so even if it is reached the stored retention is left alone rather than cleared. Test updated to cover it. Ran the suite locally: apps/dokploy test/utils/volume-backup-retention.test.ts passes (4 tests), and tsc --noEmit on apps/dokploy is clean. |
1 participant
Clearing "Keep Latest Backups" did not remove the limit. The submit handler worked out a
nullfor the empty field and then turned it straight back intoundefinedwith?? undefined. Drizzle leaves undefined columns out of the UPDATE, so the old count stayed in the database and kept pruning backups the user thought were being kept.It now sends the
null, which is what the database backup form already does. I moved that bit of normalizing into a small helper so it can be tested.The input's onChange also used to drop anything that was not all digits, so typing
3.5left the last good number sitting in the form state. It now passes the raw value to the schema, which rejects it and shows an error instead.To check by hand: set a retention value, save, reload, then clear the field and save. It should stay empty. Tests are in apps/dokploy/test/utils/volume-backup-retention.test.ts.
Closes #4184