Improve UX when $IPFS_PATH/api exists and API is offline

[lidel]

The $IPFS_PATH/api file is used by a lot of developers to talk to remote nodes (learning from ipfs-companion users). T

How to improve UX for "the API defined in $IPFS_PATH/api is offline" scenario?

Perhaps like this:

• IF $IPFS_PATH/api file exists and is different from the one in the config file
• AND IF multiaddr inside of api file points at remote API which produces ECONNREFUSED error,
• THEN ipfs-desktop should inform user about the problem with connection to remote node at {multiaddr} and display error window with built-in UI for dealing with it.

It could be a styled window similar to this mockup but with nice UI to:

• (A) Change value in api file
  • open file with $EDITOR or provide built-in editor directly in the error window similar to what ipfs-webui does
• (B) Run ipfs repo fsck
  • to remove api and potential lockfiles and try again (should be safe, technical user can always restore file by hand)
• (C) Quit

[hacdias]

Reminder to self: #711 (review).

[lidel]

(updated description to reflect what we learned during today's sync call)

[hacdias]

I believe we can close this now as #722 was closed!

[lidel]

Just tested master @ 3b7c781 and having an empty $IPFS_PATH with api file alone produces this error:

Error: ENOENT: no such file or directory, open '/home/lidel/.ipfs/config'

We need to add proper error handling for that setup :)
(We really should plan to create tests for startup logic, otherwise we will fix one thing and then break another)

[hacdias]

@lidel that error might be caused by this line which will be removed as soon as the CORS PR (#738) is merged 😄 So it won't be a problem as we won't be testing the existence of any files.

[hacdias]

That case is already solved. I'm closing this for now since we've already added the necessary logic for the scenarios here described.