Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep track of rows that were ignored because they hit the max attempt limit #1106

Open
Charles-Gagnon opened this issue Jul 24, 2024 · 1 comment

Comments

@Charles-Gagnon
Copy link
Contributor

Currently if a row fails to be processed 5 times it will be ignored for all future attempts. Logging in #1103 is being added to tell when this happens, but it would be even better to have some way of knowing exactly what rows were ignored (we can't log that information since it contains customer content).

The lease table contains this information (row keys and attempt count), but currently this is cleared once we update the last sync version in the BuildUpdateTablesPostInvocation method.

This is done so that while that version of the row is ignored forever, we will still try to process further changes in the row (in case whatever issue that caused the original failures was fixed).

But doing this means it's difficult to know what rows cause problems and easily track/reprocess those rows. Keeping a historical record of rows that failed to be processed can be hugely beneficial for auditing purposes - similar to the Dead letter queue that the service bus binding implements.

@Charles-Gagnon
Copy link
Contributor Author

Branch with work I started to simply not cleanup the leases table, but then found out that we still need to do that or we'll ignore the row forever - even if a new change comes in (which potentially could fix the issue).

https://github.com/Azure/azure-functions-sql-extension/tree/chgagnon/noFailedRowCleanup

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant