ODC Timers: The Killswitch “Gotcha” You Didn’t See Coming

If you’ve been around the OutSystems block for a while, you know the drill when it comes to Timers. We have two golden rules: keep them from timing out, and always include a “killswitch.”

In the OutSystems 11 you create a Site Property (e.g., IsKillswitchActive), and inside your heavy processing loop, you check that site property. If you need to stop the timer because something went wrong, you flip the Site Property to True in Service Center, the loop breaks, and peace is restored.

The ODC Curveball

In OutSystems Developer Cloud (ODC), we don’t have Site Properties anymore; we have Settings. At first glance, they look and feel exactly the same. You might be tempted to port your old logic straight over: create a Boolean Setting and check it inside your timer loop.

Don’t do it.

Here is the catch: ODC Settings are cached within the transaction.

Unlike O11 Site Properties, which could be re-read mid-process, an ODC Setting is read once when the transaction starts. If your timer is running along in a long process, it locks onto the value of that Setting at the start of the timer. It will not see the change of the setting …

If you go into the ODC Portal and toggle that killswitch, your running timer won’t notice. It will blindly keep processing until the transaction ends naturally or it wakes itself up again because of a soft time-out. That’s a potential disaster if you are trying to stop a runaway process. Well, a disaster?! At least it’s awkward 😉

The Workaround: Force a New Transaction

So, how do we get that “real-time” check back? We need to break out of the current transaction scope to fetch the fresh value.

Here is a pattern to solve this:

Create a dedicated “Configuration” App: Don’t put the Setting in the same app as the Timer. Create a separate application specifically for these kinds of Boolean controls.
Wrap it in a Service Action: Create a Service Action in that new app that simply returns the value of the Killswitch Setting.
Call it in the Loop: Inside your Timer’s logic in the main app, call this Service Action instead of reading the Setting directly.

Why this works: Because Service Actions run in their own independent transaction, every time your loop hits that action, it forces a fresh read of the current value from the ODC Settings.

It’s a little more overhead than the old Site.Property check, because a call to a Service Action takes more time, but it guarantees that when you hit the panic button, your timer actually stops.