You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if a function throws an exception it will fail the entire batch of rows sent, retrying them again in 60sec. This isn't great if a it was a single row that caused the exception - since it means that user functions need to be resilient to possibly retries and may end up with "good" rows being ignored if even a single bad row causes some exception.
It would be good to look into providing a way for functions to tell the trigger binding what rows it was able to successfully process and then only mark the ones that aren't in that list as needing to be retried.
The text was updated successfully, but these errors were encountered:
After discussions with team we would like to go into further detail with what you described as plausible options for enabling our SQL bindings extension to handle the issue of partial failures.
Overview of the Problem:
If a function throws an exception it will fail the entire batch of rows sent, retrying them again in 60sec. This may end up with "good" rows being ignored if even a single bad row causes some exception. Tracked here.
After some investigation I found that our SQL trigger logic we see here, we get the function result from “TryExecuteAsync” that returns the result whether it succeeds or fails. We would need to have modifications to what we get back from FunctionResult in order for us to see which specific rows failed, which would allow us to only specifically retry rows that are marked unsuccessful instead of the entire batch of rows.
As you mentioned in our discussion there is not anything built at the moment to support this or any extensions that have the ability to solve this. However you mentioned there would be ways we could work together to solve this from the Functions execution side and handle the scenario for identifying the faulty items (rows, messages, events, and collections for other extensions).
Any further contacts from your team or discussion with you on making an plan would be greatly appreciated.
Currently if a function throws an exception it will fail the entire batch of rows sent, retrying them again in 60sec. This isn't great if a it was a single row that caused the exception - since it means that user functions need to be resilient to possibly retries and may end up with "good" rows being ignored if even a single bad row causes some exception.
It would be good to look into providing a way for functions to tell the trigger binding what rows it was able to successfully process and then only mark the ones that aren't in that list as needing to be retried.
The text was updated successfully, but these errors were encountered: