Graceful recovery from JSON errors in custom blocks

[kepi]

Currently, when you have custom block witth json set to true and it returns non-json, whole bar simply breaks.

Documentation is quite clear, that you can expect something similar, but I belive that it would be much better to recover from such errors. I think following approach would be much better.

1. display error only in specific block, instead of making all blocks unusable. Simple error text in red would be enough IMHO.
2. retry JSON retrieval from custom script at next interval

It would make custom block much easier to develop. Thanks for considering this.

[MaxVerevkin]

instead of making all blocks unusable

This is a problem with all the other blocks as well: a broken block should not crash the entire bar. This is solved in async branch. For the reasons why this branch exists, refer to #430 and #1440.

It would make custom block much easier to develop

While developing a block, you can create a keybinding to restart i3status-rs in-place by running pkill -SIGUSR2 i3status-rs.

PRs are welcome.

[kepi]

Thanks for quick reply. I can wait as long as need, no rush. If async branch is solving not only whole bar break but also recovery on next retrieval, you can close this issue. I reported it because I didn't see any relevant issue opened.

While developing a block, you can create a keybinding to restart i3status-rs in-place by running pkill -SIGUSR2 i3status-rs.

I didn't mean "easier to develop" as during the development, but the fact you don't have to handle all exceptions.

Example: I'm currently hitting this problem with some elisp code which has to be executed in running emacs instance. It is working great until I'm (re)starting that Emacs. For one second it returns something else then valid json and I have to restart status bar. And yeah, I can get some layer between to handle this exception.. but then it won't be so easy.

PRs are welcome.

Sorry, but I'm already struggling with too much languages problem and this issue doesn't seem to fit in trivial fix category.

[MaxVerevkin]

but also recovery on next retrieval

No, not yet, but it can be trivially implemented by wrapping the logic with recoverable().

Sorry, but I'm already struggling with too much languages problem and this issue doesn't seem to fit in trivial fix category.

No problem.

[MaxVerevkin]

I can wait as long as need, no rush

I don't expect that branch to be merged any time soon, so...

[ammgws]

I don't expect that branch to be merged any time soon, so...

😉

Closing this since master is now async.

[MaxVerevkin]

Closing this since master is now async.

Yay!

But it's not implemented yet :)

[ammgws]

Ah my bad, I conflated it with the recoverable blocks.