So, it has been resolved right now?
Your application has a lot of business logic (codeles methods, functions, timers, etc.), for any action with blocks in them, we store changes locally for different purposes - such as changelog, etc. Therefore, due to such a large amount of data as yours, it is impossible to avoid overflowing local storage. This popup will appear when you exceed the data storage limit, and it will help you clean it up quickly and easily.
We got the undone issue again in timers.
I have changed many times the time to 60 seconds and updated start date time of timer but after few minutes of updating, changes are undone from the timer.
bad issue, we are near to launch and stuck due ti these things failing. Please help on this ASAP.
Is issue still occurs?
As I can see, timer is redeployed and now should run every 60 seconds.
Regards,
Olha
Yes, not changed now.
Its again undone to 120 sec. How can we release our build it very very bad.
Let me know if its our fault!!
That timer is in the “ChallengeService” deployment model. This means that any time any other business logic from the same deployment model is deployed, your modified timer schedule will be wiped out. I see that you have “ChallengeService” API service. Whenever you make changes to that service and deploy it, the timer schedule will go back to the one you created it with (120 seconds)
Thanks, @mark-piller ,
But I have tried changing the same to default but it also undone to the ChallengeService model.
Hi, @Baljeet_Singh
Please, describes the steps. Do you mean changing the model type in the deployed service?
Regards,
Marina
Yes
@Baljeet_Singh we already have an internal ticket for this issue - BKNDLSS-25576. It will be fixed in the nearest releases.
Regards,
Marina
For now you can replicate your timer in a separate deployment model so that it is fully isolated.
I deleted and recreated a timer for this but old timer changes are undone now which have default service
Is your new timer in a completely separate deployment model?
All timers are not set to default.
That means when you change one timer, all others will be redeployed.
Ok.
But changes should not be undone of timers
It is VERY IMPORTANT to understand the consequenses of putting multiple timers, events handlers and services in the same deployment model. If you properly use the product nothing will be “undone”. What you’re calling “undone” is actually how the product is designed, somehow you choose to keep ignoring it.
