When using the @dispatch.function registration strategy (https://github.com/stealthrocket/dispatch-sdk-python/pull/38), the user no longer has the ability to set a Status when returning from the function. The status is important because it lets the orchestrator know whether it should retry a function call.
We currently assume that when the function returns without an error that the operation was successful, and we assign a Status.OK. When an exception is thrown by the function we do very basic categorization of standard errors, for example we know that TimeoutError and Status.TIMEOUT are equivalent, and that SyntaxError is probably a Status.PERMANENT_ERROR. Real functions though may raise exceptions found in libraries, and we don't have enough information to be able to categorize errors in these cases.
This PR adds the ability to customize how statuses are derived from errors and output values. I've provided two "integrations", one for the httpx library (bundled with FastAPI), and another for the commonly used requests library. Integrations can register error types and output types, and provide a function which chooses a status when these types are encountered. This allows for fine-grained library-specific control over statuses. For example, if we see a 429 response status code we can assign a Status.THROTTLED. This greatly reduces the amount of work the user has to do to get the desired end-to-end behavior. When using httpx or requests, the user can simply response.raise_for_status().
I imagine over time we might like to add new integrations for commonly used libraries / adapters / SDKs, for example those for accessing databases and caches, or accessing AWS or GCP cloud services.
When using the
@dispatch.functionregistration strategy (https://github.com/stealthrocket/dispatch-sdk-python/pull/38), the user no longer has the ability to set aStatuswhen returning from the function. The status is important because it lets the orchestrator know whether it should retry a function call.We currently assume that when the function returns without an error that the operation was successful, and we assign a
Status.OK. When an exception is thrown by the function we do very basic categorization of standard errors, for example we know thatTimeoutErrorandStatus.TIMEOUTare equivalent, and thatSyntaxErroris probably aStatus.PERMANENT_ERROR. Real functions though may raise exceptions found in libraries, and we don't have enough information to be able to categorize errors in these cases.This PR adds the ability to customize how statuses are derived from errors and output values. I've provided two "integrations", one for the
httpxlibrary (bundled with FastAPI), and another for the commonly usedrequestslibrary. Integrations can register error types and output types, and provide a function which chooses a status when these types are encountered. This allows for fine-grained library-specific control over statuses. For example, if we see a 429 response status code we can assign aStatus.THROTTLED. This greatly reduces the amount of work the user has to do to get the desired end-to-end behavior. When usinghttpxorrequests, the user can simplyresponse.raise_for_status().I imagine over time we might like to add new integrations for commonly used libraries / adapters / SDKs, for example those for accessing databases and caches, or accessing AWS or GCP cloud services.