I haven't seen this before: I was just doing an NFT upload using the Sugar CLI. Everything went fine but at the end of the upload I saw this:
[2/2] Verification
Verifying 2000 config line(s): (Ctrl+C to abort)
[00:00:35] Config line verification successful ███████████████████████████████████████████████████████████████ 2000/2000
An item has already been minted. Skipping candy machine collection verification...
Verification successful. You're good to go!
I noticed this line: An item has already been minted. Skipping candy machine collection verification
Then when I went to the upload URL it said 17 had already been minted:
See your candy machine at:
-> https://www.solaneyes.com/address/xxx?cluster=mainnet
Then when I went to load the project on my localhost the minted number kept climbing, now it's at 214/2000 and this is without the site live on the web at all.
I'm wondering if this is a glitch that will correct itself sometime this evening or could this be a bot that is minting things?
The initial WL price is 0 and I did set the go-live date as now just for the upload and then I go in and change the date manually in the config after the upload is completed. I've done it this way in the past. Since I've set the go-live date to the future the minting has stopped.
Any ideas on the cause of this?
Bots detected your new candy machine and minted from it since it was already live. If the mint is cheap / for free there will always be bots that mint.
Solution is to simply set the go live date into the future and not now.
Related
I am just finishing an upload of 8000 assets to candy machine (via the upload command). Everything seemed to be working well when it was creating the bundles and saving them to the cache, but once it started to write the indices I've started seeing these two errors on and off:
1)
Waiting 5 seconds to check Bundlr balance.
Requesting a withdrawal of 0.638239951 SOL from Bundlr...
Successfully withdrew 0.638244951 SOL.
Writing all indices in 719 transactions...
Progress: [█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░] 2% | 18/719Transaction simulation failed: Blockhash not found
Failed writing indices 3682-3691: Transaction was not confirmed in 60.01 seconds. It is unknown if it succeeded or fail.
I have been searching the internet and from what I can tell these errors are out of my control..is this correct? Or what can I do to get these indices to write successfully? Its at 50% progress right now but I assume the upload is not going to be successful when it finishes. If this is the case, do I need to run the candy machine upload command all over again or is there a way for me to just run the transaction portion (where it started to fail) again? I've seen some notes on retry but it wasn't completely clear to me.
The upload process took about 2.5 hours so would like to avoid that if at all possible.
Help is very much appreciated.
Both errors are common so you dont have to worry about it. You should use a custom RPC (using --rpc-url on the upload command) and wait till the upload command ends. When the upload command ends you have to use verify_upload command in order to see if everything went well (if verify_upload shows an error you have to run upload again and repet till verify_upload shows ready to deploy message).
In odoo v10 Enterprise while trying to sync bank accounts for auto feed entries then getting following error.
Once your bank accounts are registered, you will be able to access your statements from the Accounting Dashboard. The available methods for synchronization are as follows.
Direct connection to your bank
Importing your statements in via a supported file format (QIF, OFX,
CODA or CSV format)
Manually enter your transactions using our fast recording interface
I would like to go with first one "Direct connection to your bank"
In that I am facing issue so I want to fix it.
Issue :
Problem Updating Account(507):We're sorry, Yodlee has just started providing data updates for this site, and it may take a few days to be
successful as we get started. Please try again later.
It is not the first time I use the Rstudio AMI from Louis Aslett on Amazon EC2, but this time the linkDropbox() function drives me crazy and I could not find any help on Google: it just doesn't give any link !
> linkDropbox()
Launching Dropbox client, please wait ...
Dropbox launched. Please visit the following URL in your browser now to link the server to your Dropbox account:
isn't
waiting (please do this now or linking may fail) ...
I don't know what this isn't do here, but there should be a link. Any one has had the same problem?
EDIT
It appears that the function gets stucks into the loop and return:
"This computer isn't linked to any Dropbox account..."
The best solution I came up with was to launch a new instance from a previous working image/snapshot - obviously not ideal if your existing instance has many packages/versions you need, but I found when I created a new AMI from Louis Aslett's site (after having trouble re-starting an old instance and updating Dropbox), I could not replicate behavior from February 2018 (except by using a snapshot of that previously functioning AMI). I am writing this in September 2018, so it is possible that the AMI's on Aslett's site will be updated and this won't be a problem anymore.
Good luck, future readers...
I had this problem, and realized that the security settings for the instance didn't allow outbound traffic on my current IP. I updated my security settings, ran unlinkDropbox(), and then ran linkDropbox() again, and it worked this time.
I'm trying to submit a new build to iTunes Connect but I keep getting this error: iTunes Store Operation failed: Error description not available while submitting.
The strange thing is that I already succeeded uploading 3 builds to iTunes Connect. But now I keep getting this error, it has been happening for 4 days now so I guess it's not an issue on Apple's servers.
I tried changing build and version numbers, as wel as re-creating provisioning profiles etc.
Who can help? After 4 days this is kinda frustrating, I need to submit this app.
Thanks for any help!
App submission requires some ports to be open, you can check the requirement document, page 6: https://itunesconnect.apple.com/docs/UsingApplicationLoader.pdf
For the best upload experience, verify that all of the ports and IP addresses are accessible
Xcode Organizer's requirements are the same with Application Loader.
Solved it. The only thing I did different this time was the location where I did it. Turned out you cannot submit apps to Apple on some networks..
Edit:
You have to make sure that ports 443 and 33001 are avalaible.
More info in this document:
https://itunesconnect.apple.com/docs/UsingApplicationLoader.pdf
I went to deploy over an existing Cloud Service (in staging) and received the following message:
"Error: No deployments were found. Http Status Code: NotFound"
Does anyone know what this means?
I am looking at the Cloud Service, and it surely exists.
UPDATE:
Been using the same deploy method as prior (successful) efforts. However, I simply right click the cloud service in Visual Studio 2013. In the Windows Azure Publish Summary, I set to: the correct cloud service name, to staging, to realease ... and press publish. Nothing special really...which is why I am perplexed
You may have exceeded the maximum number of cores allowed on your Azure subscription. Either remove unneeded deployments or ask Microsoft to increase the maximum allowed cores on your Azure subscription.
Since I had this problem and none of the answers above were the cause... I had to dig a little bit more. The RoleName specified in the Role tag must of course match the one in the EndpointAcl tag.
<Role name="TheRoleName">
<Instances count="1" />
</Role>
<NetworkConfiguration>
<AccessControls>
<AccessControl name="ac-name-1">
<Rule action="deny" description="TheWorld" order="100" remoteSubnet="0.0.0.0/32" />
</AccessControl>
</AccessControls>
<EndpointAcls>
<EndpointAcl role="TheRoleName" endPoint="HTTP" accessControl="ac-name-1" />
<EndpointAcl role="TheRoleName" endPoint="HTTPS" accessControl="ac-name-1" />
</EndpointAcls>
</NetworkConfiguration>
UPDATE
It seems that the previous situation is not the only one causing this error.
I ran into it again now due to a related but still different mismatch.
In the file ServiceDefinition.csdef the <WebRole name="TheRoleName" vmsize="Standard_D1"> tag must have a vmsize that exists (of course!) but according to Microsoft here (https://azure.microsoft.com/en-us/documentation/articles/cloud-services-sizes-specs/) the value Standard_D1_v2 should also be accepted.
At the moment it was causing this same error... once I removed the _v2 it worked fine.
Conclusion: everytime something is wrong in the Azure cfgs this error message might come along... it is then necessary to find out where it came from.
Just to add some info.
The same occured to me, my WM Size was setted to a size that was "Wrong".
I have multiple subscriptions, I was pointing one of them, and using a machine "D2", I don't know what happened, the information was refreshed and this machine disappeared as an option. I then selected "Large" (old), and worked well.
Lost 6 hours trying to upload this #$%#$% package.
I think the problem can be related to any VM Size problem
I hit this problem after resizing my role from small to extra-small. I still had the Local Storage set to the default of 20GB, which an extra-small instance can't hold. I ended up reducing it to 100MB and the deployment worked (the role I'm deploying is in maintenance mode only for a couple of months, so I don't care much about getting diagnostics from it).
A quick tip: I was getting nowhere debugging this with Visual Studio's error message. On a whim, I switched to the azure website and manually uploaded the package. That finally gave me a useful error: that VM size was too small for the resources I had requested.
I encountered this error during the initial deployment of a Cloud Service that required a specific SSL Certificate... that was missing from Azure.
Corrected the certificate - deploy succeeded.
(After the first deployment Visual Studio provides a meaningful error in this case.)