Hi @Atal Sharma ,

It could be caused by any of the issues you mentioned. Without seeing the actual logic, it’s difficult to pinpoint the exact cause. Could you share a sample OML containing your implementation?

Hi @Atal Sharma,

First I would check the logic of the action executed by the timer, check the condition responsible for when the timer wakes up again, and separately check the condition that decides if there are still records to process, so you uploaded the file then saved the records in UploadedFiles entity, you should have an attribute like IsProcessed of boolean type, if true then skip it and don't include it in the next 1000 records batch, this leads to another investigation, is the aggregate itself (UploadedFiles inside the logic flow) actually filtered by IsProcessed = False or not IsProcessed, this is important to check because if there is no filter you will keep looping and reprocessing records that shouldn't be there.

But this alone does not explain the exact symptom, 32 clean full batches then one fully empty 33rd execution, because even if the filter is correct, if the timer logic is written as fetch the batch, process it, then check if it came back empty to decide whether to stop, the timer will always fire one extra time just to find out there is nothing left, this is because the decision to invoke the action happens before it actually knows the result is empty, so this produces exactly this pattern, clean batches, then one wasted empty call, even when the filter is correct.

So there are two things to check together, is the aggregate filtered correctly by IsProcessed so you are not pulling already processed records, and is the timer deciding to fire again based on knowing there is more work before it invokes the action, or is it firing first and only checking after, the second one in my opinion can be the one that explains why you get exactly 33 executions.

Hi @Atal Sharma,
Could you please share more details about the implementation?

1.  What logic have you implemented for processing the records? 
2. What type of query are you using to fetch the records? 
3. How are you determining the batch size and the number of batches? 
4. How are you handling the records after they are processed?
5.  Are you using a For Each for batch processing? 

A few screenshots of the action flow and query configuration would also be helpful to understand the implementation and identify where the additional batch is being triggered.

A trick you can use, is to have the aggregate retrieve 1001 records instead of 1000, and the loop after it only process 1000.

In the decision to continue, you check if there were 1001 retrieved, if so, there is more to process.

But honestly, this does not sound like a problem to solve, only in cases where the records are an exact multiple of 1000, it wakes one more time and then finds it has nothing to do, why care about that ?

Adding more context to the issue:

The issue occurs specifically when the Timer fails during processing and is retried.

Current implementation:

• We use an SQL query to get the total number of staging records.
• We process records using pagination with a batch size of 1,000.
• Each record has an IsProcessed attribute.
• Once an record is successfully created, we update IsProcessed = True.
• The next batch is fetched based on the pagination/start index and the IsProcessed status.

Current values:

TotalStagingRecord = Total records from the staging entity
MaxRecord = 1000
StartIndex = 0
We are using If Condition to complete batches . 

Hi @Atal Sharma ,

Where are you maintaining the StartIndex value?

Since you already have an IsProcessed attribute, I would suggest using it to identify the remaining unprocessed records when the Timer fails and retries. This will make the retry process independent of the previous StartIndex.

I would also suggest changing the batch-processing condition from:

StartIndex < TotalStagingRecord

to: TotalStagingRecord > 0

After each batch is processed, run the count query again to get the remaining unprocessed records based on IsProcessed = False.

For example:

Get count of unprocessed records - TotalStagingRecord > 0? -  Yes  -Process next 1000 records - Update IsProcessed = True - Get count again - TotalStagingRecord > 0?

 This way, if the Timer fails after processing some records, when it retries, it will simply pick up the remaining unprocessed records instead of relying on the previous StartIndex.

I would also recommend avoiding StartIndex/Offset pagination when the underlying dataset is changing during processing, as updating IsProcessed can change the result set and potentially record to skipped or extra batch executions.

Hope this will help you.

If this is an ODC application, you can also leverage the AI Mentor to troubleshoot this type of issue.

You can simply provide the Mentor with the details of your implementation, including the Timer flow, SQL query, pagination logic, IsProcessed handling, and the retry scenario.

For example, you can paste the following prompt:

My Timer processes staging records in batches of 1,000. I use an SQL query to get the total number of records and pagination using StartIndex. Each record has an IsProcessed attribute, which is updated to True after successful processing. The issue occurs when the Timer fails and retries. For example, with 32,000 records, I expect 32 batches, but after a retry I sometimes see 33 batch executions. TotalStagingRecord is the record count, MaxRecord is 1,000, and StartIndex starts at 0. Please analyze my batching and pagination approach and identify why an additional batch is being executed after a Timer retry. Also suggest the recommended ODC pattern to process the remaining unprocessed records safely.

The AI Mentor can analyze the logic and guide you on where the issue is occurring and how you can improve the batch-processing approach.

Thank you, everyone, for your suggestions and guidance. I’ll make the recommended changes and review the entire flow again to identify and resolve the issue.