I’ve spent well over $100 today alone. All in an attempt to deploy an app. And each time It’s costing me cycles. Theres very little insight as to the cause of the failure and each hypothesis costs about $8 to test. Still don’t know what’s causing the error and so to add injury to injury, I’ll be doing this all over again tomorrow.
When I deploy my app locally, everything builds just fine, but deploying to the IC is yielding an error. That shouldn’t be the case. That error should’ve been caught during the local deploy so that I don’t have to spend $8-$10 per hypothesized solution. There needs to be some sort of test deploy process that undergoes the exact same build processes that take place when your deploying an app to the IC.
The cost of the trial and error process experienced when deploying to the IC can easily become prohibitively expensive for developers attempting to innovate and contribute to the ecosystem that aren’t funded by large-cap entities.
Have you try to import your code and deploy your app using motoko playground first ?. It can help to simulate if your app deployment will have an error. It cost you 0 cycle.
I don’t have much to say other than I empathize @Jesse . I have escalated this internally to get some folks with the right skill set looking at your experience. I think we (the IC community) can do much better for our devs.
I doubt the playground would do the trick in this case. I haven’t been able to use it for a while as it doesn’t allow you to instantiate new instances of actor classes. I do appreciate the suggestion
That error should’ve been caught during the local deploy
Agree with that. But besides this point, which hopefully can be fixed, I am curious what you are doing that could be that expensive to deploy? Are you sure it costs that much and that the cycles aren’t still sitting somewhere? Maybe the cycles were moved but not actually all spent? Just guessing…
You likely have not lost your cycles. Check your history for the canister ids that were attempted. They likely still have your cycles and you still control them, they just don’t have a wasm in them. If you issue destroy commands through your cycle wallet with the proper parameters you will get back the cycles. I’m not at a computer to look it up, but perhaps someone can help you with the dfx commands.
This is a problem that hurts developers’ confidence, belief, and wallet, and has a serious impact on the ecological development of dfinity. I hope the core team can solve this problem as soon as possible.
Thanks! ! !
The lead engineer on the SDK team has reached out to me and has assured me that the team has made this top priority. They’ll be implementing some form of a test deploy that devs can use for feedback prior to deploying. To their credit, they’ve been very receptive to this feedback.
After you deploy, do you populate the canister with any data by calling any of its methods? $8 per deploy seems prohibitive, given that I remember seeing a tweet by Distrikt that in total they’ve only spent like $70 on cycle costs in total…
I think the minimum for setting a cycles wallet is something like 2.5 XTC which would be like $2? Still should probably be free on a testnet. Of course, can also refund cycles and delete teh canister, but this is probably too much for people new to the system.
Thanks for raising this concern Jesse and I’m glad to see the team has already taken action. As others have already alluded in the thread, you likely haven’t lost your cycles and you can recover them from the canisters that have been created but do not have any wasm yet. I can understand that this is not trivial to figure out if you’re new though.
May I suggest that in the future you also share a bit more information on what the exact error you’re facing when deploying to the IC was vs the local attempts? This can help us (i) understand where the gaps are and (ii) offer you more direct help until longer term solutions (like better test deployment ground) are implemented.
@daijianlin To be fair, Diego had responded (within hours) that he had escalated internally and not long after the OP mentioned that he was in touch with the lead engineer from SDK team. So, I am not sure your comment is well founded. The team responded quickly imo. My own late response to this thread is merely because I was on vacation for the last two weeks
This will be addressed in the next release of dfx; I was able to merge the last part of the issue yesterday. I’ll see what I can do to make the release happen soon
I’m looking forward to being able to move forward.
