aboutsummaryrefslogtreecommitdiffstats
path: root/packages/meshbay-hub
diff options
context:
space:
mode:
authorChristophe Besson <cbesson@gmail.com>2026-09-10 12:20:07 +0200
committerChristophe Besson <cbesson@gmail.com>2026-09-10 12:20:07 +0200
commit6964ff112fec47498ed778a491cf2a1490392c79 (patch)
treeaf7ab9d4a9ca1cff804182b47995b6a4d4890469 /packages/meshbay-hub
parent45d63060a975473367a0f0312572b349a5c448a4 (diff)
downloadmeshbay-6964ff112fec47498ed778a491cf2a1490392c79.tar.gz
fix(node): report the transfer cap the node actually enforces
`transfer_state` read `slots.per_member` — the node-wide default — while `_has_room` decides with `member_cap()`, which prefers the group's own signed limit, and the handshake ack announces that same `member_cap()`. Three readings of one number, and one of them was the odd one out. In a group where the operator signed a higher limit, every lease update told the client "cap: 2" while the node would grant five: the transfers widget draws `used >= cap` as saturated, so a member with two transfers running saw the rest of their slots disappear. Lowered the other way it is worse in the other direction — the interface offers slots the node will queue. Nothing was ever granted or refused wrongly; the enforcement was right on both paths. It is the number beside it that contradicted them. Two tests, one override above the default and one below, because a bug that reads the node-wide value passes the first whenever the default happens to be the larger number. Node suite 1215 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AsoWC3GmhNdwVFomW3QjH3
Diffstat (limited to 'packages/meshbay-hub')
0 files changed, 0 insertions, 0 deletions