How to un-ignore a failed row?

[denious]

The Bindings Overview document states, and I quote, that "if the function execution fails 5 times in a row for a given row then that row is completely ignored for all future changes."

Is there a way to:

• catch the fact that a row will now be ignored for tracking and notification purposes
• query a list of all ignored rows
• remove a row from the "ignore list"

[Charles-Gagnon]

I've sent out a PR to update our documentation for the 2nd & 3rd item, let me know if there's anything else you need there!

#756

(note that the current version of the extension doesn't have the new Leases table log message emitted, so you'll have to enable Debug logging and then look there for the leases table name until the new version is released)

For the first item I've opened an issue to add this as we don't currently emit any sort of message or have any other indication that a row is ignored.

#757

[denious]

Thank you, @Charles-Gagnon, this helps!

In the context of the trigger binding, given the following parameters and a list of 5000 pending changes:

• Sql_Trigger_MaxBatchSize: 1000
• Sql_Trigger_PollingIntervalMs: 60000
• Sql_Trigger_MaxChangesPerWorker: 1000000 (so we don't need to consider scaling)

Given code that fails to execute correctly for a single row change in each batch, would all 5000 rows be marked as failed in a span of 25 minutes, 5 minutes per batch?

We are building a webhook solution that is expected to send 0-N events per row change, and our concern is that:

• if we fail the entire function due to a failure in processing a single change, then the entire batch processing will be retried 5 times in a row, resulting in duplicate events being sent for 999 changes and eventually still being ignored, requiring another re-processing when all rows are re-enabled
• if we swallow single change errors and mark the batched function execution as complete, then we need a separate storage solution for re-processing only the failed rows separate from the SQL Trigger flow

Is it possible to fail execution of specific rows only so only specific rows are marked as failed?
What are your thoughts overall?

[Charles-Gagnon]

Yes, they'll all be marked as ignored in ~25min. Although typically I would expect that the first batch is going to be marked as ignored first in 5min, then it'll move on to the next batch which would be ignored at 10min and so on. This isn't deterministic though, it depends on the order that we get the rows from the CHANGETABLE function in.

Unfortunately, it's a limitation of the current implementation that you can't specify to ignore only certain rows in a batch. It's a good point that this could be a problem though, so I've created an issue to track improving this, so keep an eye on that for any updates there.

#771

In the meantime I can't think of any workaround that doesn't involve doing something similar to what you said or changing the batch size/polling interval to process smaller batches more often (which would at least limit the number of rows affected by this issue).

[jmarbutt]

Would triggering service bus queue after row change trigger, be a better option to ensure durability? This way the service bus trigger would be the one that failed, not the row trigger? Or is there another more reliable approach?