Improve UX when API is unstable

[fiatjaf]

When browsing a web page that does 4 simultaneous ipfs.dht.findprovs and one ipfs.object.stat calls, sometimes the companion crashes.

I start seeing lots of ERROR engine: open /home/fiatjaf/.ipfs/datastore/004159.ldb: too many open files engine.go:258 in the daemon logs.

Then the web page calls to ipfs fail silently, I think.

The IPFS Companion status window starts showing everything offline,

and then if I restart the daemon I get

If I wait more, the status window comes back to normal, but in the meantime some, or all, of my ipfs.dht.findprovs have already failed silently.

[lidel]

@fiatjaf thank you for reporting this with all the details!

Then the web page calls to ipfs fail silently, I think.

Correct. I see the go-ipfs part ("too many open files") is tracked in ipfs/kubo#5739, so let's keep this issue about how ipfs-companion should behave in such situations.

• the UI is faded out if API is unreachable (this seems to work as expected)
• idempotent notifications (there should be no duplicates)

Is there anything else we should improve here UX-wise?

[fiatjaf]

Well, this is probably unrelated but I would like stuff being printed to the console when the Companion is doing work. Perhaps there could be a debug mode I could put the extension on so that it would start printing a lot of things? I don't know.

Currently (at least on Firefox) nothing shows up in the Network tab, nothing is printed to the console. Things that fail silently are very annoying, but I can't even know they're failing silently, maybe they're just not failing and taking a lot of time.

[lidel]

I agree! Been playing with verbose logs that can also be filtered via Preferences screen in #557. The PR was parked due to a dependency bug, but I see that got released recently, so it may be a good idea to get back to it in near future :)

[lidel]

Closing updates:

• configurable logger namespaces landed in Support configurable logger namespaces #712
• ipfs-companion requires HTTP API exposed by go-ipfs, and if it is unstable, we can't do much about it, however:
  • "too many open files" in go-ipfs is tracked in "too many open files" without doing anything kubo#5739, seems to be mitigated
  • there is experimental work on embedded js-ipfs in Brave (Embedded JS-IPFS in Brave (experiment) #716), which does not rely on go-ipfs