mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-22 08:02:24 +00:00
l0ng-ai
a7bdade300
The managed-forward form in the Forwards panel used to bare-`return` from Add whenever the fields did not make a rule — an unparseable bind port, a target port of 0, an empty target host for a Local or Remote rule. The button did nothing, said nothing, and left the form exactly as it was. It now collects the fields through the same conditions the settings sheet applies (`ForwardRuleForm::collect`), keeps Add disabled while there is nothing to add, and shows the settings sheet's own "needs both" / "needs a listen port" line under the form once it has been touched. Saving an edit removed the old forward and then added the new one, so a rule that could not be started took a working forward with it. Remove-then-add is still the order — the ordinary edit keeps the bind port, and adding first would collide with the very rule being replaced — but the panel now looks at the entry the add appended, and on `ForwardStatus::Error` it takes that entry back out, puts the old rule back, and keeps the form open with the reason under it. `mf_editing` carries the whole `ManagedForward` rather than an id so there is something to put back, and it is re-pointed at the restored entry, which comes back under a new id. Adjacent, and the reason a failed request could not be told from a successful one: `ForwardRoute::add`/`remove` and their `RemoteTerminal` fallbacks turned every transport error into an empty `Vec`, which the caller then assigned straight into the panel's list — so one unreachable round trip blanked a panel full of live forwards. They return `Option` now, and the panel only takes a list the far side actually sent.