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

How to decode last_error? #449

Open
mlafeldt opened this issue Nov 19, 2024 · 7 comments
Open

How to decode last_error? #449

mlafeldt opened this issue Nov 19, 2024 · 7 comments

Comments

@mlafeldt
Copy link

Hey @geofmureithi,

It looks like Apalis always serializes the original error inside FailedError, e.g.

  "last_error": "{\"Err\":\"FailedError: unexpected error: Uncaught PermissionDenied: 'Deno.exit' is not allowed in this context.\\n    at Object.exit (ext:runtime/30_os.js:80:5)\\n    at <user_provided_script>:1:24\"}",

How are consumers of that string supposed to deserialize it? I want to access the original error type.

Is there a way to remove the error envelope? I added ErrorHandlingLayer, but it did not change how errors are serialized.

@mlafeldt
Copy link
Author

I'm using the chore/v0.6.0 branch.

@geofmureithi
Copy link
Owner

This should be straight forward to resolve.

  1. We will rename it to last_result to avoid the confusion.
  2. You need to deserialize it as a Result<Res,Err> instead of Err, as seen here

Let me know if 2 works because it should work out of the box.

@geofmureithi
Copy link
Owner

Also, please note that the error type does not expect to be Serialize, but rather its converted to string and thats what is stored. I might work on something with the error handling layer to customize this.

@mlafeldt
Copy link
Author

Oh, I'm already trying to deserialize it as Result. Works fine for the Ok case, but the FailedError envelope gives me trouble in case of Err.

@geofmureithi
Copy link
Owner

I think I can work on the error handling layer to allow using crates like https://docs.rs/serde-error/latest/serde_error/

@geofmureithi
Copy link
Owner

But its important to note this message on the crate:

In some other cases it may make sense to serialize the whole causality chain, but most often it makes most sense to just not serialize errors.

@mlafeldt
Copy link
Author

Yeah, you're probably right. It looks like the original error isn't serialized, so the inner error is just converted using to_string.

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

2 participants