Summary of the Issue in the PR
The change introduced in the PR modifies the error returned by the mint function in pallet_assets when the asset is in destroy mode (i.e., start_destroy has been called). Previously, the function returned the module error pallet_assets::Error::AssetNotLive, but now it returns DispatchError::Token(Token::UnknownAsset).
Why is this a problem
For downstream projects, e.g. contracts, applications or a chain consistency in error outputs is critical. Let’s take the example of a chain aiming to provide stable, versioned APIs to smart contracts—like Pop Network with the Pop API—that ensures contracts do not have to deal with breaking changes in runtime behavior. This change in error behavior makes it exceedingly difficult, if not impossible, to provide a stable API.
In attempting to map the AssetNotLive error from mint to TokenError::UnknownAsset for consistency, the following challenge arose:
- Scenario 1: Minting an asset in destroy mode correctly maps
AssetNotLivetoTokenError::UnknownAsset. - Scenario 2: Minting an asset that does not exist also maps to
TokenError::UnknownAsset, which introduces ambiguity.
There’s no reliable way to differentiate between these scenarios without querying state to determine whether the asset exists—an additional complexity that defeats the purpose of consistent error handling.
This inconsistency arises because the SDK does not define when a dispatchable function (or the pallet as a whole) should return specific errors like AssetNotLive or TokenError::UnknownAsset (another example I encountered some time ago). This lack of definition leaves downstream projects guessing, making stable error output nearly impossible to achieve.
Closing Thoughts
Polkadot’s strategy is to target applications, applications want stability, and this issue highlights a gap in the SDK that can hinder adoption. Other ecosystems set a precedent by offering defined and stable APIs with consistent error handling for their smart contracts and integrations. If Polkadot aims to be a go-to platform for developers building long-term solutions, ensuring consistent, defined error outputs for SDK pallets is a necessity.
We hope this explanation provides a clear overview of the issue and why we believe it is significant. This is a problem that we think needs solving, and we are eager to discuss it further with the community to explore potential paths forward.
Best regards,
Daan | R0GUE