v2.5.5
Recovery fix for a persisted config that could brick spoofer jobs.
Fixed
- "Validation failed: max_concurrency 1000 vs 100" blocked every spoof run. The concurrency inputs in Settings → Routing had no min/max attribute, so a user could type a value above the backend's accepted range, and the value got persisted to localStorage. Every subsequent job start died at the validator — users couldn't recover without knowing to open Settings and lower the number by hand. Now three-layer safe:
- The inputs clamp to [1, 100] on change.
- On app load, any stored value above the range gets clamped in place (self-heals bad configs from earlier builds — no user action required).
- The backend silently clamps instead of hard-failing so a bad payload from an older client still runs the job.