You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Deleting the Populate Markers trigger stops its automatic runs only until the next server update. After the server starts with the new version, the default trigger reappears without an administrator adding it back.
Steps to reproduce
Open the Populate Markers scheduled task.
Delete its trigger and save the empty trigger list.
Install a new server version.
Reopen the task's schedule. Its default trigger has returned.
Expected behavior
The saved empty schedule remains empty across server restarts and upgrades. Automatic runs resume only after an administrator adds a trigger.
Affected source
The defective startup logic is present at server commit 25e460ff. PR #991 contains the fix at 188a57f3.
Clients affected
Web administration of server scheduled tasks; the underlying defect is server-side.
Relevant logs
No logs available.
Technical notes
Source inspection and automated regression tests confirmed that startup uses an empty trigger list to decide whether defaults should be persisted. Removing the last trigger leaves no rows in task_triggers, so startup cannot distinguish an intentionally cleared schedule from an unconfigured task. Populate Markers defaults to a daily trigger at 03:30.
The same path affects other tasks with nonempty defaults when all triggers are removed. Added or modified triggers, and partial deletions that leave at least one trigger, were preserved in the restart tests. A plain server restart exercises the same initialization path, so the defect is not specific to the installation process.
Fix: #991. It records initialized schedules independently of trigger rows and preserves empty schedules during startup. Previously restored triggers must be deleted again after all server instances are upgraded.
Involvement: AI-assisted report; technical notes are AI-generated source analysis supported by automated regression tests.
Adversarial review: The same agent reviewed the implementation's startup, migration, persistence, and concurrency paths. An eager-default lookup regression was reproduced and fixed before PR fix(tasks): preserve schedules during startup initialization #991 was opened. No independent reviewer was used.
What happened
Deleting the Populate Markers trigger stops its automatic runs only until the next server update. After the server starts with the new version, the default trigger reappears without an administrator adding it back.
Steps to reproduce
Expected behavior
The saved empty schedule remains empty across server restarts and upgrades. Automatic runs resume only after an administrator adds a trigger.
Affected source
The defective startup logic is present at server commit
25e460ff. PR #991 contains the fix at188a57f3.Clients affected
Web administration of server scheduled tasks; the underlying defect is server-side.
Relevant logs
No logs available.
Technical notes
Source inspection and automated regression tests confirmed that startup uses an empty trigger list to decide whether defaults should be persisted. Removing the last trigger leaves no rows in
task_triggers, so startup cannot distinguish an intentionally cleared schedule from an unconfigured task. Populate Markers defaults to a daily trigger at 03:30.The same path affects other tasks with nonempty defaults when all triggers are removed. Added or modified triggers, and partial deletions that leave at least one trigger, were preserved in the restart tests. A plain server restart exercises the same initialization path, so the defect is not specific to the installation process.
Fix: #991. It records initialized schedules independently of trigger rows and preserves empty schedules during startup. Previously restored triggers must be deleted again after all server instances are upgraded.
AI disclosure
functions.exec,exec_command), GitHub CLI (gh),silo-bug-reportand repositoryunslopskillsgpt-6-astra