Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI and python client get the error types and error docs from metadata #384

Closed
3 tasks done
sam0x17 opened this issue Apr 30, 2024 · 6 comments
Closed
3 tasks done
Assignees
Labels
blue team defensive programming, CI, etc

Comments

@sam0x17
Copy link
Contributor

sam0x17 commented Apr 30, 2024

It's pretty annoying that the UI doesn't know at all what errors are if they haven't been hard-coded. Unknown error isn't a great user experience, and right now introducing new error types or errors in new situations creates a lot of churn with releases.

Substrate provides the metadata, which includes all info about errors, calls and events.
At first, we must guarantee all of them are well documented. In this issue, all docs for errors are checked.

From this unit test file for metadata check, the structure is clear for other language like python and js to parse.
https://github.com/opentensor/subtensor/blob/development/runtime/tests/metadata.rs

  • add these as doc comments for the errors
  • add unit test in the runtime to guarantee docs is ok for new added errors
  • profit?

fixes #375

@sam0x17 sam0x17 added the blue team defensive programming, CI, etc label Apr 30, 2024
@sam0x17
Copy link
Contributor Author

sam0x17 commented May 1, 2024

Synced with the @opentensor/cortex peeps, this is how we will pass it to them:

We will add an RPC call that produces a JSON map of all error codes => { name, description } for each error. Client will hold off on calling this RPC endpoint until the first time they encounter an error, then they will hit the endpoint and cache the map (probably in a local file). Later, if they ever hit an error code that isn't in their local map, they will hit the endpoint again. In this way, we will always be able to display names and descriptions for errors coming from subtensor, even if new ones are introduced in a chain upgrade that bittensor doesn't specifically know about.

cc @unconst ^

so data coming back from that endpoint will look something like:

{
    "0": {
        "name": "SomeError",
        "description": "Thrown when yeet and something something"
    },
    "1": {
        "name": "AnotherError",
        "description": "This is a description something something"
    },
    "2": {
        "name": "YetAnotherError",
        "description": "This is a description something something"
    }
}

@sam0x17 sam0x17 assigned sam0x17 and open-junius and unassigned sam0x17 May 2, 2024
@sam0x17
Copy link
Contributor Author

sam0x17 commented May 2, 2024

I would recommend doing something like this rather than Display actually:

pub trait SubtensorError {
    const NAME: &'static str;
    const DESCRIPTION: &'static str;
}

@distributedstatemachine
Copy link
Contributor

Related : #375 cc @camfairchild

@sam0x17 sam0x17 mentioned this issue May 6, 2024
13 tasks
@sam0x17
Copy link
Contributor Author

sam0x17 commented May 6, 2024

partially fixed by #391

@sam0x17
Copy link
Contributor Author

sam0x17 commented May 6, 2024

right now it looks like the way forward is actually just using regular substrate metadata, which @open-junius has implemented in #391

@open-junius
Copy link
Contributor

From this unit test file for metadata, the structure is clear for other language like python to parse.
https://github.com/opentensor/subtensor/blob/development/runtime/tests/metadata.rs

@open-junius open-junius changed the title maybe require Display on our error types and give UI access to this UI and python client get the error types and error docs from metadata May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blue team defensive programming, CI, etc
Projects
None yet
Development

No branches or pull requests

3 participants