* feat(clients): support setting HWID limit and MTProto ad-tag in bulk adjust
Add HWID device limit and Telegram MTProto sponsor channel (ad-tag)
support to the bulk client adjustment flow in both the panel API
and frontend ClientBulkAdjustModal.
Co-Authored-By: Claude Code <noreply@anthropic.com>
* fix(clients): gate adTag to MTProto inbounds and avoid inbound rewrite for limitHwid
Co-Authored-By: Claude Code <noreply@anthropic.com>
* fix(clients): stamp updated_at only on the clients a bulk adjust changed
The updated_at write was gated on hasInboundChanges, which accumulates
over the whole inbound instead of describing the client in hand. Once any
client in the settings array changed, every client after it was re-stamped
as well, so whether an untouched client kept its own updated_at depended on
its position in the array. That field feeds node-snapshot conflict
resolution, where a spurious bump lets a stale snapshot value win over the
stored record.
Track the change per client and fold it into the inbound-level flag where
the stamp is written, so the early return still skips a save whose settings
JSON would be unchanged.
Also condenses the BulkAdjust doc comment back to the two-line maximum.
* docs(api): regenerate the bulkAdjust reference for limitHwid and adTag
frontend/public/openapi.json was copied to docs/public/, but pnpm gen:api
was never re-run, so the API reference page's heading, anchor id and search
index still described bulkAdjust without limitHwid or adTag. docs-ci.yml
fires only on docs/**, and that path had been touched, so nothing flagged
the stale MDX.
The externalLinks hunks are the generator rewrapping lines main had left
stale, not a content change.
* fix(i18n): stop enumerating fields in the bulk-adjust empty-form message
bulkAdjustNothing listed the fields the form accepts, so it went stale
every time one was added: only en-US ever gained "flow", leaving the other
twelve locales describing days and traffic alone, and limitHwid and adTag
would have repeated that. Say that one field is required instead of naming
which, so the message cannot drift again.
63b46cd6 made a multi-inbound client create apply its inbounds concurrently,
and d34ec97f did the same for the single-client update, delete and detach. The
bulk operations were never converted, so they still walked their inbounds in a
plain sequential loop with a node RPC in each iteration — and those are what the
panel actually calls for a multi-select delete or an enable/disable, which is
why editing and deleting still felt slow on a master with several nodes.
Measured with a node runtime injecting 100ms per RPC, one client per node:
nodes=1 update=101ms bulkSetEnable=101ms bulkAdjust=101ms bulkDelete=101ms
nodes=3 update=102ms bulkSetEnable=302ms bulkAdjust=304ms bulkDelete=303ms
nodes=5 update=203ms bulkSetEnable=504ms bulkAdjust=504ms bulkDelete=504ms
after, all of them track the single-client ops:
nodes=3 bulkSetEnable=103ms bulkAdjust=101ms bulkDelete=101ms
nodes=5 bulkSetEnable=202ms bulkAdjust=202ms bulkDelete=202ms
Generalize the fanout into fanoutInboundResults over an arbitrary per-inbound
result type and route six loops through it: BulkDelete, BulkSetEnable,
BulkAdjust, BulkDetach, BulkAttach, BulkCreate, plus applyClientFieldByEmail —
the field edit behind the Telegram bot's enable/limit/expiry buttons and the
LDAP job. Each keeps its preparation sequential and overlaps only the node
pushes, inheriting the same concurrency cap and per-inbound panic recovery.
Two ordering details the sequential loops got for free and the fanout must do
itself: the three loops that ranged a map now walk sortedInboundIds, so which
inbound wins a per-email skip reason is the lowest id instead of whatever the
map yielded; and BulkAttach de-duplicates a repeated inbound id up front,
because the second pass used to see the client the first pass had just added.
The allocating paths stay serial when a tunnel inbound is involved. WireGuard
and AmneziaWG pick a free peer address by reading every inbound's used-set
before they write, so two overlapping allocations hand out the same address and
the in-transaction re-check refuses the loser — a bulk create of two clients
onto two wg inbounds returned created=1. addFanoutLimit drops those batches back
to one at a time; every other protocol keeps the full cap.
Eight tests: seven barrier tests that a sequential caller cannot satisfy (peak
pushes in flight is 1 without the change, 4 with it), and one that pins the
tunnel allocation.
Rouzbeh†