Skip to content

v1.2.4

Choose a tag to compare

@FFidan FFidan released this 07 Aug 17:23
· 2 commits to main since this release
a6a7a87

v1.2.4 — a bot that starts, an upgrade that finishes, and the checks that prove both

A patch release that repairs two paths broken for people running the software rather than reading about it: the Telegram bot container could not start, and upgrades from older installations could not finish. Both had been shipping for several releases with no check that would have noticed, so each fix arrives with the check that was missing.
This release carries no database migrations and needs no operator action beyond the upgrade itself.
This release changes application code, so the :1.2.4 images differ from :1.2.3.

Fixed

  • The Telegram bot container starts again. Deployments using the telegram profile have been unable to start it since v1.2.0: the published image was missing a dependency the bot imports at startup, so the container exited immediately and restarted forever. This affected v1.2.0, v1.2.1, v1.2.2 and v1.2.3, every release in that range. The dependency is now declared where it is used, and every published image that carries a Python interpreter imports its entry point with that interpreter before its digest may join a release manifest, so an image whose entry point cannot be imported is never released.
  • Updates create the secret files they manage before touching anything. Since v1.1.3 the deployment has referenced an SMTP password secret file that no updater before this release created, so on installations first set up before v1.1.3 the update stopped part way through replacing containers. The update now creates the secret files it manages — the SMTP password file among them — before it pulls, builds or replaces anything, and an update that cannot create them stops with everything still running and names the command to run.
  • Lists say when a query failed instead of showing the same empty state they show when there is genuinely nothing to display, and the automation settings controls stay inert until real values arrive rather than offering fabricated defaults that a stray blur could persist over real server state.
  • A single paper reports where it came from, matching the origin already shown in list views.
  • A missing-table error names the schema baseline to apply, so the message points at the fix rather than only reporting the failure.
  • Dependency floors were raised to their patched releases for the HTTP/2 library, the frontend's YAML parser, and the web framework, so no declared version range admits a release carrying a known advisory.

Changed

  • Documentation that contradicted the code was corrected, covering configuration precedence, ownership rules, route behaviour, and the conditions under which strict mode and extraction failures raise.
  • The installer, upgrade, backup and restore scripts are now covered by shell linting, alongside the entry points that were already checked.
  • Model-catalog freshness is checked in the repository, not at runtime. The bundled model catalog was re-verified against its providers for this release, a scheduled repository check now fails when any entry goes unreviewed too long, and the application no longer logs catalog-age warnings at startup. The top-tier local entry advances to the current generation, qwen3.6:35b-a3b, whose 24 GB footprint leaves room for long-context work on 48 GB hardware.
  • The release guide states what each image check proves and how far upgrades reach back, naming the in-image import check, the window of supported upgrade sources, and the documented path for installations older than every supported source.

Upgrading

An installation already on v1.2.3 upgrades in place:

jarvis-research update

An installation on v1.1.3, v1.2.0, v1.2.1, or v1.2.2 runs the one-time bootstrap from the installation directory:

(
  set -e
  bootstrap="$(mktemp)"
  trap 'rm -f "$bootstrap"' EXIT
  curl -fsSL -o "$bootstrap" \
    https://raw.githubusercontent.com/limitcycle-oss/jarvis-rd-assistant/v1.2.4/scripts/update-bootstrap.sh
  bash "$bootstrap" --repo "$PWD" --to v1.2.4
)

An installation first set up before v1.1.3 needs one extra one-time step before either path, because the SMTP password secret file it never created must exist before Compose can start; the command-line reference gives the exact commands.

Either path validates the selected release, creates and authenticates a restore point, stages the new images, advances the checkout fast-forward only, and commits after services report healthy.

Full changelog: CHANGELOG.md