Repository navigation
fix: restore dokploy-server schedule runs - #9
Merged
Merged
Conversation
Что: - В runCommand возвращена ветка `else if (scheduleType === "dokploy-server")`, как в upstream. Её код остался в файле, но после слияния upstream 5a1d8ea (2026-10-01) оказался внутри ветки application/compose. - Тесты: расписание dokploy-server запускает ./script.sh из своей папки и получает статус error, если скрипт падает; расписание приложения выполняет только команду в контейнере. Зачем: - С 2026-10-01 расписания dokploy-server вообще не запускались, но получали статус done. Так на dev молча перестал работать ночной дамп баз. - Расписания application и compose после своей команды дополнительно запускали `bash -c ./script.sh` в папке расписания. Такого файла у них нет, поэтому успешный запуск помечался как error. Риски: - Поведение возвращается к upstream, других изменений нет. Проверки: - Команды и результаты: CI=true bunx vitest run --config __test__/vitest.config.ts __test__/schedule/schedule-command-boundary.test.ts - на старом коде 3 новых теста падают (скрипт не запускается; статус done вместо error; два вызова spawnAsync вместо одного), после правки проходят все 9; все тесты __test__/schedule и __test__/backups/volume-backup-restart.test.ts - 33 прошли. Полный прогон: 2073 прошли, 1 пропущен, 8 упали только в *.real.test.ts (нет сокета Docker Desktop). bun run typecheck - 4/4 без ошибок. bun run format-and-lint - 0 ошибок. - Ограничения: на сервере исправление ещё не проверялось; ночной дамп на dev один раз запущен вручную, свежие дампы есть. What: - runCommand gets back the `else if (scheduleType === "dokploy-server")` branch, as in upstream. Its code was still in the file, but after the upstream merge 5a1d8ea (2026-10-01) it ended up inside the application/compose branch. - Tests: a dokploy-server schedule runs ./script.sh from its own directory and gets the error status when the script fails; an application schedule runs only its container command. Why: - Since 2026-10-01 dokploy-server schedules did not run at all but still got the done status. That is how the nightly database dump on dev silently stopped. - Application and compose schedules also ran `bash -c ./script.sh` in the schedule directory after their own command. They have no such file, so a successful run was marked as error. Risks: - The behaviour goes back to upstream; nothing else changes. Checks: - Commands and results: CI=true bunx vitest run --config __test__/vitest.config.ts __test__/schedule/schedule-command-boundary.test.ts - on the old code the 3 new tests fail (the script does not run; done instead of error; two spawnAsync calls instead of one), after the fix all 9 pass; all tests in __test__/schedule and __test__/backups/volume-backup-restart.test.ts - 33 passed. Full run: 2073 passed, 1 skipped, 8 failed only in *.real.test.ts (no Docker Desktop socket). bun run typecheck - 4/4 clean. bun run format-and-lint - 0 errors. - Limitations: the fix has not been checked on the server yet; the nightly dump on dev was run once by hand, so fresh dumps exist. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this PR about?
runCommandinpackages/server/src/utils/schedules/utils.tslost itselse if (scheduleType === "dokploy-server")line in the upstream merge 5a1d8ea (2026-10-01). The branch body stayed in the file but ended up inside theapplication/composebranch:donewithout executing the script. A nightly database dump on dev stopped silently this way.bash -c ./script.shin the schedule directory. They have no such file, so a successful run was markederror.This PR puts the line back, matching upstream canary.
No migrations and no new environment variables; only the
dokployservice image changes.Checks
__test__/schedule/schedule-command-boundary.test.tsfail on the old code and pass now: a dokploy-server schedule runs./script.shfrom its directory, a failing script giveserror, an application schedule runs only its container command.__test__/scheduleand__test__/backups/volume-backup-restart.test.ts: 33 tests pass.vitest run: 2073 pass, 1 skipped; the 8 failures are only in*.real.test.ts(no local Docker socket).bun run typecheck: 4/4 packages pass.bun run format-and-lint: no errors.Rollout notes
After rollout, run a dokploy-server schedule manually (or wait for its next run) and check that its log shows the script output and the expected files appear.
🤖 Generated with Claude Code