[@kadena/graph] Normalized error handling

[MRVDH]

This PR contains several things:

• We have a function that checks what type of error is being thrown, and formats them to a normalised error message, since we have errors coming from multiple systems, not just one.
• Since chainweb-node and kadena/client don't throw clear messages, we try to infer the type and the meaning of the error based on the error object we get.
• We will keep adding different types of errors and their infered meanings the more we find.

[changeset-bot]

🦋 Changeset detected

Latest commit: 1d36f9e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@kadena/graph-client	Patch
@kadena/graph	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

4 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
alpha-docs	⬜️ Ignored (Inspect)	Visit Preview		Nov 6, 2023 1:17pm
docs-storybook	⬜️ Ignored (Inspect)	Visit Preview		Nov 6, 2023 1:17pm
react-ui	⬜️ Ignored (Inspect)	Visit Preview		Nov 6, 2023 1:17pm
tools	⬜️ Ignored (Inspect)	Visit Preview		Nov 6, 2023 1:17pm

[nil-amrutlal]

Looks quite good to me 🙌🏽🙌🏽
Taking into account the difficulties in type safety and the different types of responses we can have, I don't see a better way of uniformizing error handling

[nil-amrutlal]

There's some conflicts to be resolved, but apart from that everything looks good 🚀 🙌🏽

[nil-amrutlal]

General remark: Should we maybe add a timeout to the subscriptions?
In the graph-client it just stays in loading state if a certain non-existing request-key is the input. Maybe a timeout, with an error message and a 'Try again' button would be nice?
Also some validation on the input of the request key would be nice. At the moment I can search for 123 as request key (when we know it has a defined length).

I think all these are out of scope but just things I noticed while testing these changes.

[alber70g]

Can this be done with import?

Suggested change

	require('module-alias/register');
	import('module-alias/register');

[MRVDH]

It can, but the auto sort for imports will move it down. For now it's okay, but it will break if an import is sorted above it that uses module aliases.

[alber70g]

Ah good one. Yes we can ignore the auto-fix I think?
This is one of the reasons we used to have a custom order. Sometimes you need a order when importing like that.

What happens when you use import 'module-alias/register'?