Breadcrumbs in error message that point to server side source files

[bobwith2bees]

Request - Could we get some filename/line cross references in the protocol error messages so that we can better understand some of the error messages we are receiving? Since the protocol is open source, it would be easier to help ourselves and peek a the server side implementation, perhaps reducing the support load on the development team.

For example I am working on lazy minting a 721 NFT and I get the error:
response: {"status":400,"code":"INCORRECT_LAZY_NFT","message":"TokenId must start with first creator address"}
--> can we add source filename/line number to the message? (assuming coding macros can do this)

Then I am off on a rat-hole trying to understand why a creator address is used to check a tokenId. The tokenId is a bigInt not a hex number in the protocol. If "begin" means it starts with the same hex value of an address.. then what is the total field size in bytes because there needs to be a token id in there too right? Am I going way off spinning my wheels here? etc... ;-)

Alternatively, we could use an error message FAQ, so we can quickly understand the top x things that cause a given error message. I am just thinking that will take more time to develop, so peeking at the server code might be best for now.

[bobwith2bees]

FYI - I found the TokenId format information here: https://docs.rarible.org/asset/creating-an-asset#asset-types-explained . So having that as additional context for this error message would be nice. This is all "operator error" on my part, so there is only so much you can do. Hah...

How did I get started on this rathole? - Well the following api call appears to omit the minterId in the response. Probably because I created the collection with the rarible.com UI, but didn't finish approval or pricing transactions before I started calling generate_token_id?

• http://ethereum-api-staging.rarible.org/v0.1/nft/collections/0x6855d041dae27e4dfe3413bc0c14a3d8620e6ce9/generate_token_id?minter=0x72a4408da42de870499c1841d0e4a49f864e34ba

I can "fix" it easily enough by detecting the TokenID is less than a 12 byte value and "add" the minter address << 12*8 bytes. But adding more crazy is not always the best approach. ;-)

[evgenynacu]

@rarible/tech-writer-protocol-team could you take a look if we can improve this on documentation side?

[eduardstal]

@kolberszymon

[eduardstal]

After discussing with Denis & more members of the protocol team this won't be worked on.