Candy Machine V2 Upload Bug

[tracy-codes]

Describe the bug When running the upload command from candy-machine-v2-cli, the metadata json file that's uploaded on chain does not have the correct imageUrl and associated URIs for each file. This looks like it's a bug with the closed-source arweave upload endpoint.

See here for an example metadata file that was uploaded, you'll see it just has the .png filename and not the replaced arweave link. https://gjphq3ceikqnuygzkkvi36ahwijoj4ym7aobyymkfu5pvmhb53ja.arweave.net/Ml54bERCoNpg2VKqjfgHshLk8wz4HBxhii06-rDh7tI/

To Reproduce Steps to reproduce the behavior:

1. Go to the js/packages/cli folder
2. Run ts-node src/candy-machine-v2-cli.ts upload example-assets --keypair ~/.config/solana/id.json -cp ./example-candy-machine-upload-config.json -e devnet
3. Open up the generated .cache/devnet-temp.json file
4. Copy one of the link attributes and paste it into your browser.

Expected behavior When uploading, it's expected that the cloud function that handles uploading to arweave will upload the image first, replace the image link in the metadata, and then upload the metadata second. Right now it looks like that is not happening.

Screenshots N/A Desktop (please complete the following information):

• OS: Windows 10 w/ WSL (ubuntu)
• Browser Brave
• Version 1.33.106

Smartphone (please complete the following information): N/A

Additional context I monkey-patched this in my repository by performing two separate uploads to the cloudfront endpoint. First upload is just for the image link, and then a second upload is performed with the updated metadata file. This is not an ideal patch and the upload endpoint needs to be patched.

[tracy-codes]

This is apparently resolved by replacing 0.png with image.png in the metadata file that's supposed to be uploaded. This is an important change that should be documented as currently this is not compatible with current expectations of the candy machine cli.

[0xmathisd]

I confirm, it is necessary to use in the json "image": "0.png" rather than "image": "image.png". And increment for each of the collection.

[ArunSankarKs]

So what's the fix, replacing 0.png with image.png or vice versa? running into the same trouble :/

[tracy-codes]

So what's the fix, replacing 0.png with image.png or vice versa? running into the same trouble :/

Looks like it's intentional to use "image.png" or "image.gif" in your metadata files. If you run the verify_token_metadata command, it will give you a warning telling you it's expecting the image and uri fields to be "image.png".

The upload command should handle replacing this field if it's not already correct and isn't already a URI.

[github-actions[bot]]

This Issue has received no activity for 30 days. We will close it in 2 days, please reopen if you are still experiencing this issue.

[tevinm1]

If you go to /Src/main.js goto line 158 Itll say Uri. Change "image.png" to '${edition}.png' the metadata will no longer say image.png.

assuming your using hashlips to generate the art.

[l8nit3tr0ubl3]

I also have this issue, uploaded 1337 images+data pairs, and many seem to have worked fine. However (so far) one of my minted items seems to only have "932.png" as the image URI in the arweave uploaded metadata.

I managed to mint 50 through the CLI interface (combination of mint_one_token and mint_multiple_tokens) with no issues, and one using windows 10 chrome on the cady-machine-ui without issue. All metadata links correctly, and images show correctly.

Then , I had a friend try aswell through chrome on android, mint succeeded, however metadata doe snot have the updated URI for the image.

In original .json file, they use the 0.png, 1.png paradigm and not image.png.

output of "verify_upload": Key size 0 uploaded (1337) out of (1337) ready to deploy!

Do I have to withdraw rent, and forfeit fees paid? Or is this fixable as-is? https://kjbxb2ohywqvb7sz2upvsd4p7xwfnfbz6myhcrx4zgpehkrljguq.arweave.net/UkNw6cfFoVD-WdUfWQ-P_exWlDnzMHFG_MmeQ6orSak/

[stegaBOB]

This is interesting. That shouldn't happen. The initial issue was fixed after this issue was opened a couple months ago. Would you mind opening a new issue using our issue form to provide a bit more details @l8nit3tr0ubl3. Thanks

[bypina]

I'm still getting this issue and changing it to image.png doesn't do anything , it was literally working a week ago

Has anyone found a good fix for this?