Repository navigation
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
latestfallback that could relabel an unrelated binary as the requested version and write a misleading.telemt_versionmarker. If the exact registry tag is unavailable, build the pinned source instead.cargo build --lockedin both build paths.strip; make explicit source builds bypass image pulls and handle failed exact-tag creation.Validation and rollout
telemt 3.5.14.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).