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

Better Error Propagation #4279

Open
cali-jumptrading opened this issue Feb 24, 2025 · 0 comments
Open

Better Error Propagation #4279

cali-jumptrading opened this issue Feb 24, 2025 · 0 comments
Assignees

Comments

@cali-jumptrading
Copy link
Contributor

cali-jumptrading commented Feb 24, 2025

We should propagate errors as structs with a type and error code, and only set the error into the task info context once to avoid error overwrite errors and clean up code.

This would look like returning a struct that looks like this:

struct __attribute__((packed)) fd_exec_result {
  /* kind and err matching agave */
  uchar kind;
  schar err;

  /* custom err is a u32 in agave */
  uint custom_err;
};
typedef struct fd_exec_result fd_exec_result_t;

For VM errors, the proposed returned error struct would look like this:

struct fd_vm_result {
  fd_exec_result_t exec_res;
  int err; // this can be a schar to save space
};
typedef struct fd_vm_result fd_vm_result_t;

Open to other suggestions as well! The motivation for this proposal is to remove the need for the developer to remember to set error details via macros like https://github.com/firedancer-io/firedancer/blob/main/src/flamenco/runtime/context/fd_exec_txn_ctx.h#L169. Using these macros before returning can be easily forgotten or accidentally called more than once up the call stack (when returning errors).

Example of forgotten ERR_FOR_LOG: #4025
Example of overwritten error: https://github.com/firedancer-io/firedancer/pull/4069/files#diff-7068ff1660560ece7e7d6a7c6848146e115fc8ad40dd3addaab552703d70b15eR414

@cali-jumptrading cali-jumptrading self-assigned this Feb 24, 2025
@cali-jumptrading cali-jumptrading changed the title Error Propagation Better Error Propagation Feb 24, 2025
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