Countdown Timer does not stop producing records

Hi all

I have a countdown timer in a custom list just like Victor’s video with the order item cloning.

My use is to generate new records in a different collection for each record in the existing filtered list.

The countdown timer continues to run even after I leave the screen and go back to the previous screen. Let’s say I want to create 10 new records in the new collection from 10 records in the original collection, the process apparently finishes but when I go back to the previous screen, records keep being created. In fact, if I don’t kill the preview app, I can get hundreds of records created in a couple of minutes.

I have tried the tricks with changing visibility of the timer based on the updated first collection records, but the timer keeps creating records even when it should be invisible.

Help?

Hey @bchavis,

This is quite interesting. Timer continues to work when you leave the screen (going “forward”), but it should stop doing anything after it finishes. The only way I know to restart the timer is to hide it and show again (could be the timer itself or parent element).
I can only imagine that list refresh may restart the timer, but I haven’t seen that. Could you share screen recording showing the issue?

Best,
Victor.

Here is the link to a video. I am about 18 months in Adalo and have two pretty good commercial apps.
This app has 25 companies and over 150 users.

Here is the video of the app issue…I can show you the back screens if you want.

https://youtube.com/shorts/_Rx54wuhWv4

Hi Brian @bchavis,

This is very bizarre. Definitely not the expected behaviour.
I didn’t manage to replicate issue in a sample app - the timer properly stops. Could you share more details on how the list w/timers is configured, how timer is configured?
Or maybe you could try replicating the setup in a separate app (just the timer part) and share it?

Best,
Victor.

I can get to it later today. I really appreciate your help.

I had the same issue with countdown doing ‘loop’ actions even if the screen was already changed. What i do usually is to put the countdown sometimes visible, and assign a boolean value for the user (example loading true/false). On the screen in which the countdown is present, i do action on screen - update logged in user - loading true.
When the countdown finishes, do his actions but also update logged in user - loading false. This method allows me to use the countdown without the ‘loop bug’. Hope this helps

@Eugen In the video it continues to create records, which shouldn’t happen IMO. No list item → no countdowns.
Visibility helps (of course keeping in mind that making it visible again may lead timer to appear on some screens in the history.. or may not, this is undefined). But as @bchavis mentioned visibility also doesn’t help in his case.

So more info is needed :slight_smile:

Thanks all for your help. I believe it is now working. As suggested, I implemented the boolean input field and set visibility on the countdown timer to it.

This input field is set by the button on the calling screen before linking to the countdown screen.

Also, I put in a button for the user to click which changes the boolean to turn on the countdown timer.

Before I had the countdown timer visible and running when the screen was opened with visibility set to a value inside the list item. Once the record in the custom list was approved, the timer was supposed to go invisible.

In hindsight, that was probably a bad idea.

Thanks again!

1 Like

Hi @bchavis,

Thanks for the update! Happy that you have this resolved.

Still I can’t replicate your original issue :slight_smile: I managed to implement the infinite record creation, but this was with 2 subsequent actions on a timer (hide list item → show list item). And timer (+ list items) are clearly visible, unlike your case. And “link back” kills the screen as expected. So your issue is still a mystery :slight_smile:

Best,
Victor.

One more point I forgot to mention…

The screen with the custom list and timer was in my production version for over a year and worked fine until about a week ago. One more item to add to the mystery!

Thanks again!

I responded too soon. The behavior is still happening. All I am doing is trying to mark records in a collection with true or false. The screen gets to the last few and does not complete. When I leave the screen it keeps running.

What information do I need to provide?

Hi @bchavis ,

You could share the timer configuration with screenshots or using screen recording. Also how do you go to and from the screen(which actions are used).
And if you could share the reduced app version with only timer screens - that will be ideal.

I tried to replicate this infinite-working timer multiple times, but didn’t succeed, so I wonder what specifics have you got in your setup.

Best,
Victor

I have 6-8 screens that use the countdown timer. Some of them that I have redone work perfectly. Some are still having the same problem. It is as if they cannot commit the updates on the last couple of records to process. If I kill the screen and go back in and retry on the remaining records it works.

The screens that work are creating records. In the screens that do not work, all I am trying to do is modify the custom list records and update a true/false property.

I have time tomorrow to dig into this and generate another video.

Thanks!

Hi I have been working with countdown for a long time in my apps and it has always worked fine, when I saw this problem I tried to do a simple test like deleting records from a list if they met a true/false condition and I realized that something is happening because it keeps trying to delete records even when the list is gone and when the screen has been changed. I just get a message at the bottom of the screen that says “internal server error”.

For what it’s worth I noticed that some records that were supposed to be deleted (because they appeared and then disappeared from the list when the countdown deleted them) were still appearing in the database.

In the test I did and in my humble opinion I think failure is due to the database does not update or at least it does not update as fast after the countdown executes the action or It could also be that my browser has problems with the cache (im using chrome last version) as I keep seeing the records in the database that are supposed to have just been deleted and until I refresh the editor window they stop appearing in the database. Maybe that’s the reason why the countdown doesn’t stop, maybe the component also keeps seeing the records in the database… although the strangest thing is why it keeps trying to delete or execute some action if the screen has already changed.

I hope my comments help.

*I also will test on brave to see some different results.

Thanks for your helpful comments.

I think I have solved the problem with creating extra records.

Now I just have the problem that you have described with the last few records hanging in limbo until I either kill the app or refresh the editor.

I am going to run a couple more tests to see if the issue is that I am updating a property in the custom list that is involved in the list filter.

Is this the case for you?

Hello @bchavis in my case i delete the record directly then the following action is “back”.

Hi @bchavis updating my previous answer, I have fixed the problem in my case.

I used a boolean value for the countdown action when this will happen this “sometimes”. (used an input field)

The newly deleted records continue to be seen in the database until the editor is refreshed but in the application the records effectively no longer exist and do not appear.

I share the workaround that works for me

1.- Create an input field in screen #1 (the screen that contains the countdown component)
2.- When user visit screen #1 in the screen actions “change” the input field value to 1.
3.- In the countdown setting under “when the count finish action” choose “the action will happen sometimes” when the “input field” value is equal to 1" (after the action it’s completed no need to change the actual input to any value because the countdown actually stops looping)

I hope it work for you too.

Hello all

I am happy to keep this discussion alive. I really believe something changed at Adalo because the behavior of my screens changed after a year in use.

My app is working now and here is what I have learned…

Do not update a property in a collection with a countdown timer when the property exists in the filter for the custom list.

I hope people prove me wrong, but I have worked around this by making sure that my custom list filters are not involving any updates through the timer.

Of course, I am producing bigger lists but it works. I was trying to filter the lists to be more efficient. In my case, I was just trying to set a T/F property for records that were already T to F…just clearing a print queue.

But the T/F Property was involved in the filter for the list.

Once I took that out, it worked. Instead of filtering on 20 records that are T and change to F, I just run through 1000 and turn them all to F. It seems to be fast enough for my users and it works.

Another thing I learned along these lines, is the production of new records. I use a countdown timer to run through records and create a new print record for each one.

This was producing more print records than original records. (see post above)

Again, the filter issue came into play. In the click actions, I first marked the original record “processed” with a T/F and then created the new record.

But the original record was involved in the filter for the custom list. So I changed the order of my click actions to create the new record before marking the original record as processed.

Then no more additional records being produced. Feel free to call me stupid for doing this in the wrong order.

Anyway, thanks all for your help!

Hi there,

I still can’t replicate the issue, all my timers work correctly, what am I doing wrong? :grin:
Here is a video with some testing, everything works: Adalo Experiments 2025 - 26 May 2025 | Loom

@Fercho just in case this works correctly with 1 timer; I expect that if you have a list, some timer will update the field faster, and therefore others may glitch.

@bchavis it is not a good idea to run countdown timer on a large list. The reason is: when countdown finishes, all timers will try to run an action. You can imagine that if, say, 100 queries are send to the backend at the same second, the result may not be successful due to sudden workload burst.
As about T/F in the list filter - I would disagree, see my video. It’s great that it worked for you but I can’t understand why it wasn’t working before.
Regrading the creation sequence - I’d say that proper approach is first to create new record, then mark the original as “done”. My rationale behind it: if we do it vice-versa, there is a risk of concurrent actions with uncertain result. First, record marked as done → the visibility should become false → the component with timer should disappear; OR element conditions in list filtering changed → the component with timer should disappear. BUT there is a subsequent action on the timer. Which creates a question: what will happen earlier - the component disappearing / list element disappearing, or next action execution? And this may depend on the device speed, list size, etc.

Unfortunately the issue remains a mystery for me, because there is no clear way to reproduce the bug.

Best,
Victor.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.