Updating Condor

Updating is admin-only and available from both surfaces, over one shared engine: /update in Telegram and Settings → Updates in the Workspace. They are two views of the same run, so an update started in Telegram can be watched to completion in the browser and vice versa — starting a second one hands you back the one already in flight rather than queueing it.

​

What can be updated

Two components, versioned by what actually governs them: The API always runs the published image: an update pulls the new image with docker compose pull. If you built your own image locally, the update leaves it alone and tells you so.

​

Preflight: what is in the way

Before anything runs you get the blockers, the warnings, and the ordered plan. Blockers stop the update and say why in terms you can act on — the checkout is not a git repo, it has commits the remote does not (so it cannot be fast-forwarded), local changes would be overwritten, or the registry could not be reached. Where a blocker has a safe way out it offers one: a dirty checkout can be resolved with Discard or Stash without leaving the panel. When every conflicting file is an edit to a shipped agent under agents/, it also offers Keep my version, which moves your edit to .condor/agents/ (where it keeps overriding the shipped file) and lets the update go ahead. Warnings never refuse — they tell you a consequence worth knowing: restarting the API container stops its executors, and Condor keeps running the code it booted with until it restarts.

​

The restart step

An update lands the code, syncs dependencies and rebuilds the Workspace, then hands you the moment to restart, because bots may be trading and a chat may be mid-answer.

• Workspace: a banner says Condor has been updated. Restarting in 5s to apply it and then restarts Condor and reloads the page. Bots and open positions are not touched. Cancel stops the countdown; the banner then offers Restart now for when you are ready.
• Telegram: /update shows a Restart Now button.
• Shell: make restart works too.

The restart is in place: Condor shuts down cleanly and replaces itself under the same process, so no second copy comes up on the port. Restarting needs the admin role; a seat without it is told to set role: admin in config.yml or run make restart on the host. If Condor does not come back, the banner says so and the reason is in .condor/restart-failure.log. The run is journalled to data/update_run.json at every step, so the panel picks the result back up across the restart and the next boot tells you whether the update worked.

​

Update notifications

Condor checks in the background and tells the admin when a component falls behind — once per update, not once per check, so deferring one does not bury the rest of your notifications. Each surface gets a next step it can actually take: a Telegram message, and a bell entry that opens the update panel for a browser-only admin. Tune it with UPDATE_CHECK_INTERVAL in .env — seconds, default 3600, and 0 disables the checks. The first runs 30 seconds after startup.