feat(mtproto): add MTPROTO backend type and Mtproto proxy - #3
Conversation
Sync the service proto with PasarGuard/node: BackendType.MTPROTO, a Mtproto proxy message (secret, user_ad_tag, max_tcp_conns, max_unique_ips), and Proxy.mtproto. Regenerate the gRPC/protobuf code and add a CreateMtproto helper, extending CreateProxies with the mtproto argument. Quota and expiry are intentionally omitted; the panel owns them. Ref: PasarGuard/node#61
WalkthroughAdds MTProto as a new backend type: ChangesMTProto Backend Addition
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
🧹 Nitpick comments (1)
bridge_test.go (1)
69-69: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd one positive MTProto fixture path.
This update only preserves the pre-existing
nilpath, so the newCreateMtproto(...)/Proxy.Mtprotowiring still has no direct test coverage. A small test that passes a non-nilMTProto config and asserts it survivesCreateProxies/CreateUserwould catch future regressions cheaply.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@bridge_test.go` at line 69, Add a positive MTProto test case alongside the existing nil path in bridge_test.go so the new CreateMtproto and Proxy.Mtproto wiring is actually exercised. Update the relevant bridge test around CreateProxies and CreateUser to pass a non-nil MTProto config, then assert the resulting proxy/user state preserves that configuration instead of only covering the nil case. Use the existing CreateMtproto, CreateProxies, and CreateUser symbols to anchor the new coverage.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@bridge_test.go`:
- Line 69: Add a positive MTProto test case alongside the existing nil path in
bridge_test.go so the new CreateMtproto and Proxy.Mtproto wiring is actually
exercised. Update the relevant bridge test around CreateProxies and CreateUser
to pass a non-nil MTProto config, then assert the resulting proxy/user state
preserves that configuration instead of only covering the nil case. Use the
existing CreateMtproto, CreateProxies, and CreateUser symbols to anchor the new
coverage.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 77b5f85e-b105-4c0a-be20-e9dd6d7f2fef
⛔ Files ignored due to path filters (2)
common/service.pb.gois excluded by!**/*.pb.gocommon/service_grpc.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (3)
bridge_test.gocommon/funcs.gocommon/service.proto
Syncs the bridge with the new MTProto backend in PasarGuard/node (PR #61).
Changes
BackendType.MTPROTO, aMtprotoproxy message (secret,user_ad_tag,max_tcp_conns,max_unique_ips), andProxy.mtprotocommon/service.pb.goandcommon/service_grpc.pb.gocommon/funcs.go: addedCreateMtproto(secret, userAdTag, maxTcpConns, maxUniqueIps)and extendedCreateProxieswith themtprotoargumentNotes
Data quota and expiry are intentionally not part of the message. The panel owns quota and expiry enforcement (usage reporting plus user sync), the same as for the xray and wireguard backends, so the node never hands them to telemt.
CreateProxiesgains a trailingmtproto *Mtprotoargument, so callers must pass it (usenilwhen not configuring MTProto).Summary by CodeRabbit
New Features
Tests