Skip to content

fix(engine): pin Telemt 3.5.14 and avoid relabeling registry latest - #157

Open
rmtshnik wants to merge 2 commits into
SamNet-dev:mainfrom
rmtshnik:codex/telemt-3514
Open

rmtshnik wants to merge 2 commits into
SamNet-dev:mainfrom
rmtshnik:codex/telemt-3514

Conversation

@rmtshnik

Copy link
Copy Markdown
Contributor

MTProxyMax pins Telemt 3.5.9, where an ME pool can lose writers and fail to converge after reconnects or generation updates. Pin Telemt 3.5.14 (9d5b896bb695c55e2905b82f276da84e45a0a2ec), which includes autonomous, lifecycle-bounded ME pool convergence: https://github.com/telemt/telemt/releases/tag/3.5.14.

Why this change

In an IPv4 Docker host-network deployment using a local TCP tunnel to a SOCKS5 server at the egress, 3.5.9 initially connected all DC groups and served the sponsored channel, but subsequently degraded to 1–2 active writers against a target of 43. One snapshot showed a pending generation aged 966 seconds, no warm writers, and no refill tasks in flight. A five-minute log contained 212 successful RPC handshakes and no connection-timeout messages, yet the active pool remained depleted.

Ordinary HTTPS through both the tunnel and the SOCKS server continued to work during the degradation. Separate tests passed with up to 10 concurrent HTTPS requests and five established connections surviving 120 seconds of idle time. These observations narrow the problem but do not rule out every network issue. The symptoms overlap with telemt/telemt#941, without being identical.

With the same egress and configuration, an amd64 build of the pinned 3.5.14 commit retained 43 healthy active writers at the follow-up snapshot, advanced to generation 2, and had no pending hardswap. The available log covers approximately 25 minutes and shows replacement/refill after idle closures. This is a short production observation, not a full-day soak test or proof that every issue is fixed.

Changes

  • Update the manager pin and manual image-build workflow defaults together.
  • Remove the registry latest fallback that could relabel an unrelated binary as the requested version and write a misleading .telemt_version marker. If the exact registry tag is unavailable, build the pinned source instead.
  • Check out and verify the full commit SHA and use cargo build --locked in both build paths.
  • Preserve compile failures rather than masking them with optional strip; make explicit source builds bypass image pulls and handle failed exact-tag creation.
  • Add mocked regression coverage for cache/pull/source paths, failures, version markers, and build-command error propagation.

Validation and rollout

  • The pinned source was built on Debian 12 amd64; the binary reports telemt 3.5.14.
  • Initial ME startup and all 12 DC groups succeeded through a compatible SOCKS5 egress.
  • The previous container/image were retained for rollback; clients and the configuration were preserved.
  • Automated regression and distro tests are run in the linked fork CI. ARM runtime behavior has not been tested in this deployment.

Before release, publish the exact new registry tag from the updated build workflow. Until it exists, installs will compile from source rather than silently accepting registry latest.

Fork CI: https://github.com/rmtshnik/MTProxyMax/actions/runs/39008907039 (all five distro test jobs and systemd/OpenRC integration passed; lint status is visible in the run).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant