Oh, sorry, I just found out, I took the code of my own test jar,
This problem only appeared
//This is the interface container
mjj2h-niaaa-aaaaa-qbbrq-cai
//This is the front-end container
m4olk-maaaa-aaaaa-qbbsa-cai
Sorry, it was my mistake
Thanks for pointing out
Sorry, Iām still rather confused.
Either the source or some abstraction of the source would help to debug. Is there a change of representation involved during upgrade, i.e. converting a hashmap to an array of entries or something like that?
If you are, for example, using an operation like Array.append in a loop, then you could easily wind up allocating a quadratic amount of memory before the garbage collector has a chance to run.
But itās very hard to tell without seeing some abstraction or explanation of the code.
Do you have any idea if the error is happening while the previous canister is saving its state for the new one, or while the new canister is trying to create its state from the stored state of the previous canister?
Hello, sorry because I am in utc-8 time zone, please forgive me for taking so long to reply to you.
When I checked the newly deployed container today, I was trying to push my newly modified code, and found that the new container also promptedāContainer is not empty and needs to use --mode=reinstallā mode to install. . Why is the current state of the subnet container so unstable? This unstable state does not meet the standards of a public project?
The new container mentioned here is not moi4t-aqaaa-aaaaa-qbbra-cai, sorry, it may be a mess of container id for you.
Is it convenient to tell me the status of the current test subnet?
Or how can I get the latest status of the subnet?
I am very helpless. Until now, I still cannot find a solution to deal with my problem. All services in the current subnet cannot be deployed with containers, and I donāt know the status of the current subnet. I cannot get this information.