Open cosmicpoet opened 1 year ago
Thank you for the detailed issue!
Inventory
is basically a type-erased wrapper around Warehouse
or Factory
. Both Warehouse
and Factory
are objects from which NFTs can be withdrawn thus anyone interacting with an Inventory
does not necessarily need to know what object theyre withdrawing from.
This property is useful for creating simple market interfaces as you can create venues that sell pre-minted NFTs or mint them on the fly.
Our developer docs might be able to provide you with some extra insight in the future https://origin-byte.github.io/inventory.html#Inventory
Going back to your issue, based on the transaction effects after publishing your contract I understand that your mint_nft
endpoint is expecing a &mut Warehouse
which you are correctly providing and its erroring out.
The reason this is erroring out is that you cannot make a direct mutable reference to a child object of another object. Since the Warehouse
has been inserted into Inventory
it is now a child object and Sui transaction rules will not allow you to reference to it directly without going through the Inventory
.
You can modify your endpoint to take &mut Inventory
instead and call inventory::deposit_nft
but I suspect that this also wont work because you have also inserted the Inventory
into the Listing
which makes it a child object (same problem).
To resolve this you can modify mint_nft
to call https://origin-byte.github.io/listing.html#add_nft which you will call with the inventory_id
0x474be3d63ecd613cc42515671ced2d75ae462042
. Let me know whether that works!
To give you a bit more insight about why the mint_nft
function is generated with &mut Warehouse
in the first place. Calling listing::add_nft
on Listing
which is a shared object will force the transaction to go through shared consensus. Mass depositing your NFTs into Warehouse
while it is still owned by your address allows you to avoid that. (Though there is a blocking issue for this functionality https://github.com/MystenLabs/sui/issues/8689)
Thank you @Suficio for the detailed explanation!
I redeployed my package using the updated mint_nft
function as you suggested calling listing::add_nft
, and it worked! I had to make my own MoveCallTransaction
instead of relying on the NftClient.biuldMintNft()
(a glaring typo here...) in your js-sdk
but that's alright for testing purposes for now.
To give you a bit more insight about why the mint_nft function is generated with &mut Warehouse in the first place. Calling listing::add_nft on Listing which is a shared object will force the transaction to go through shared consensus. Mass depositing your NFTs into Warehouse while it is still owned by your address allows you to avoid that. (Though there is a blocking issue for this functionality https://github.com/MystenLabs/sui/issues/8689)
Based on your description, Gutenberg generates mint_nft
function that way by design, but then it just violate Sui transaction rules? Are we expecting changes to Gutenberg generated contracts (which is normal I guess for anything in Sui at this stage)?
Lastly, is this document about deployment still accurate?
Based on your description, Gutenberg generates mint_nft function that way by design, but then it just violate Sui transaction rules?
In your case you are minting NFTs after attaching the Warehouse
to the Listing
, whereas for many workflows we mint before attaching the Warehouse
in which case minting to Warehouse
is the correct approach. We will make sure that a function that allows minting into Listing
is generated in the future for cases like yours.
I'll pass the info regarding the typo along, it is glaring...
Regarding deployment the info is accurate, however you can chose to reference the currently published contract of the protocol instead of publishing it yourself each time.
Thanks for the feedback!
Thanks again for your guidance.
Feel free to close it but just leaving some comments for others who are confused like me. Currently (0.26.0 / SUI 0.27.1) the best way for end-to-end deployment is to follow one of the example contracts in this repo (e.g. suimarines.move). After deploying the contract, head over the js-sdk and use the 0-9 scripts to initialize the warehouse, listing, venue etc.
Gutenberg-generated contracts don't seem to be updated to the current configuration and would probably need a lot more efforts to make them work.
I am not really sure if it's better to post this issue in the js-sdk repo or this one. But here we go.
What I have done:
/sources
directory, along with the existingnft-protocol
modules.addresses
field inMove.toml
from the existing one you had in your repo into0x0
, or otherwise I was NOT able to deploy it.It seems that this has to do with the
inventory
andwarehouse
objects. In general, I found the relationships between the two very confusing and there isn't enough documentation explaining them. But from the transaction log above and Sui Explorer, it seems that myinventory
object0x474be3d63ecd613cc42515671ced2d75ae462042
owns a dynamic field that is thewarehouse
object0x3eb3968cd02a9ff3cd6225465de9fa23ad382bd1
. My guess is that there is some incompatibility between what's generated from Gutenberg and js-sdk regarding these two objects.Understanding this is a very lengthy issue post already and I tried not to overload information further. If necessary I can provide more info or push my repos to help with replication and investigation. Really have 0 clue on how to even debug this issue so I appreciate your guidance.