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

feat: allow ActorErrors to carry optional data #1093

Merged
merged 2 commits into from
Jan 24, 2023
Merged

Conversation

arajasek
Copy link
Contributor

Extracted from the next branch.

Currently unused, but can be used to carry (optional) return data using the FVM3 SDK's exit method.

@codecov-commenter
Copy link

codecov-commenter commented Jan 23, 2023

Codecov Report

Merging #1093 (9c445b7) into master (dfe0676) will decrease coverage by 0.12%.
The diff coverage is 50.00%.

❗ Current head 9c445b7 differs from pull request most recent head 610f0c5. Consider uploading reports for the commit 610f0c5 to get more accurate results

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1093      +/-   ##
==========================================
- Coverage   89.32%   89.21%   -0.12%     
==========================================
  Files          93       93              
  Lines       19590    19611      +21     
==========================================
- Hits        17498    17495       -3     
- Misses       2092     2116      +24     
Impacted Files Coverage Δ
runtime/src/actor_error.rs 77.41% <50.00%> (-10.94%) ⬇️
actors/miner/src/testing.rs 91.80% <0.00%> (-0.98%) ⬇️

runtime/src/actor_error.rs Show resolved Hide resolved
/// Returns the optional data that might be associated with the error
pub fn data(&self) -> &[u8] {
self.data.as_ref().map_or(&[] as &[u8], |d| d.data.as_slice())
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realise this might have been written with some code in mind that we can't see here, but this seems like an oddly specific conversion to inline right here. Discarding the codec on purpose? Why not provide &Option<IpldBlock> and let the caller do what they need with it? Or some other variant.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell, it's only used in a couple of tests.

(IIRC, it was written this way before we started using IpldBlock, and it should definitely be removed).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, I've removed it.


/// Creates a new ActorError. This method checks if the exit code is within the allowed range,
/// and automatically converts it into a user code.
pub fn checked(code: ExitCode, msg: String) -> Self {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recognize this code as being copied (twice) from runtime/fvm.rs. I don't think it belongs here. It's appropriate only in the case of receiving an exit code from a send, not in various other places that exit codes propagate.

If you factored this match block out from the runtime as a helper function, adapt_callee_code or similar, that might be ok. But who's going to call it except the runtime? Links to how this is used might help.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@anorth Good call, thank you. I'm going to refactor runtime/fvm.rs to use this method, instead, if that works for you. I'm also dropping the repeated copy -- just one checked method is sufficient, I think.

@arajasek arajasek force-pushed the asr/errors-with-data branch from fb91885 to 9c445b7 Compare January 24, 2023 02:00
@arajasek arajasek force-pushed the asr/errors-with-data branch from 9c445b7 to 610f0c5 Compare January 24, 2023 02:02
@arajasek
Copy link
Contributor Author

@anorth I'd like your opinion on whether you think it'd be good to unify unchecked and unchecked_with_data. One fewer method, but almost all calls (~50/55). to the unified method will supply None as the optional data.

Copy link
Member

@anorth anorth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I wouldn't unify them.

@arajasek arajasek merged commit ea76792 into master Jan 24, 2023
@arajasek arajasek deleted the asr/errors-with-data branch January 24, 2023 19:02
shamb0 pushed a commit to shamb0/builtin-actors that referenced this pull request Jan 31, 2023
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

Successfully merging this pull request may close these issues.

4 participants