HydraIssues

Problem

The hydrastreamingmonitor auto-updater (6-hourly check via hydrarelease) downloads and installs whatever version hydrarelease considers latest. This overwrites manual SCP deploys, so any new code shipped outside the CI pipeline gets silently reverted within 6 hours.

This has happened repeatedly: we deploy v0.4.22 via SCP, and by next check the server is back to v0.4.29. We deploy v0.4.30, and v0.4.31 needs another SCP. The cycle repeats every release.

Root cause

The hydrarelease mirror upload path (project/production/version/binary-name) does not match the GET redirect URL the updater uses (releases/project/platform/arch/binary-version). This means binary downloads from the mirror return 404. However, an older binary at a legacy path on the release server IS downloadable, so the updater successfully installs that stale version instead of failing cleanly.

Impact

• Every new hydrastreamingmonitor release requires a manual SCP deploy to the server
• The auto-updater then overwrites it with the stale version from hydrarelease
• New features shipped in a release are unavailable until the next manual deploy
• Operators have no indication the running version is stale

Fix options

1. Fix the mirror path in hydrarelease — align the upload path with the GET redirect URL so binary downloads succeed. This is the correct long-term fix and likely affects all services using the auto-updater.
2. Pin the version in config — add a pin_version field to the updater so the service does not self-update beyond a specified version. Workaround only.
3. Disable auto-update for hydrastreamingmonitor — if the service is always deployed via CI anyway, the auto-updater adds no value and only causes regressions.

Recommended

Fix option 1 (mirror path alignment in hydrarelease). Investigate whether other services are silently affected by the same path mismatch.

Project

hydrastreamingmonitor (symptom), hydrarelease (root cause)