Closed 0x234 closed 5 years ago
:+1: At first I thought that's good to fail loud and early, but then realized we're only warning on other errors in the json
file, so we can sweep json encoding errors under the same handler there, around the line mentioned in the upper stacktrace.
Hmmm... the json is falsely encoded. What else should have happened?
@InoMurko see my comment, we're more forgiving when json is correct but something inside is not. I think extending that forgivingness to the case of bad json makes sense. If not, then for consistency, we'd probably like to crash also on these other types of errors.
It might be better to limit ourselves to handling correct inputs and throw a fit otherwise. It quickly gets exponential trying to handle everything.
hm, crashing on a typo in the fee specs file sounds a bit severe. Also, note that in case of a warning-only-inducing-error, the old fee specs are in effect.
Normally I'd opt for crashing on any erroroneous input/config from the operator's part. But now, as we're after the HA, I'd opt for letting it run + old fees + warnings (alert maybe, in the future?)
I'm ready to start on it, let's summarize what will be done here.
Operator has an option to switch off fee checker entirely with config :omg_child_chain, :ignore_fees
.
When this isn't the case, fee checker needs to deal with possible file format errors or input errors.
Fee checker periodically checks for fee file updates, whenever any previous file was loaded, if last version has issues it will:
WARN
periodically about file issue and continue working,My opinion is, that until we don't have a very good alarming and reporting system in place we shouldn't continue working
if fees file is corrupt.
Or let's say it otherwise: if the fee file is corrupt at boot - die immediately. If the file is changed on run time and it's corrupt, continue working but alarm.
if last version has issues it will:
... or will ignore the fees otherwise
The alternative is "or will work off of an empty fee specs", i.e. not allow any tx through at all.
I think what you propose is better after all - it feels it is slightly better to run the child chain with no fees than to halt txs altogether, at least in current circumstances.
What could be added is an alarm being fired when the Fee checker encounters issues.
My opinion is, that until we don't have a very good alarming and reporting system in place we shouldn't continue working if fees file is corrupt.
considering that when the fee file is corrupt, the old one is in effect. The change from old to new is most likely adding a new token or altering the fee, not fixing a critical issue mandating dying.
I still opt to continue working
.
EDIT: I've just noticed your comment update :joy:
Or let's say it otherwise: if the fee file is corrupt at boot - die immediately. If the file is changed on run time and it's corrupt, continue working but alarm.
this is very good actually, let's do this!
Best description of the work remained @InoMurko:
Original @jbunce message goes :point_down: