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

Runtime: Don't convert syscall errors #1024

Merged
merged 1 commit into from
Jan 13, 2023
Merged

Runtime: Don't convert syscall errors #1024

merged 1 commit into from
Jan 13, 2023

Conversation

arajasek
Copy link
Contributor

@arajasek arajasek commented Jan 12, 2023

filecoin-project/ref-fvm#1020

Open questions:

  • Is it fine to make the runtime always depend on the SDK? (and less importantly, for test_vm to do so?
  • EVM: Is converting the SyscallError into an ActorError at the interpreter's system level fine (for now)? I'm guessing we'll want to actually propagate and handle differently at the callsites (or at least do more nuanced handling here), but that can be deferred so long as this isn't a regression.
  • We can reduce the code duplication in the test runtimes by having them do the same thing that the "actual" FVM runtime does (and moving that logic into the trait itself). The only loss is some information in test failures (since ErrorNumbers don't contain message strings).
    • @Stebalien is in favour of making this change, so gonna do that.

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.

I didn't see the introduction of send_generalised, but when this comes to master I will strongly argue for collapsing to a single send method (possibly with a trait helper with default impl that fills in the flags). I think different return types from different methods is technical debt we should not take. Instead, we should do the work to update existing callers to the new, better way. That will solve the duplication item.

Given the current package architecture, we should not add fvm_sdk as a dependency of crates that don't use the actual FVM. Instead, move the required types to fvm_shared, along with many similar. I could be convinced that a different package architecture would make sense in which the SDK is always a dependency, but then would want to see things moved back the other way so there's a consistent decision logic for what lives where.

params: Option<IpldBlock>,
value: TokenAmount,
) -> Result<Option<IpldBlock>, ActorError> {
// TODO gas_limit is current ignored, what should we do about it?
Copy link
Member

Choose a reason for hiding this comment

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

This TODO isn't helpful - there's nothing concretely to do or a condition upon which to do it. It's fine that gas limit is ignored, just leave a comment without TODO.

@Stebalien
Copy link
Member

I didn't see the introduction of send_generalised, but when this comes to master I will strongly argue for collapsing to a single send method (possibly with a trait helper with default impl that fills in the flags).

That's how it's currently implemented:

/// Sends a message to another actor, returning the exit code and return value envelope.
/// If the invoked method does not return successfully, its state changes
/// (and that of any messages it sent in turn) will be rolled back.
/// Note that the current return type cannot distinguish between a successful invocation
/// that returns an error code, and an error originating from the syscall prior to
/// invoking the target actor/method.
fn send(
&self,
to: &Address,
method: MethodNum,
params: Option<IpldBlock>,
value: TokenAmount,
) -> Result<Option<IpldBlock>, ActorError> {
self.send_generalized(to, method, params, value, None, SendFlags::empty())
}

We wrote it this way to reduce the diff between the next branch and master and to avoid any unnecessary refactors while diverged.

Once we merge, I'd be strongly in favor of removing the separate method and/or cleaning this up. However, I couldn't directly port these changes over to master because they rely on features that don't exist in FVM 2.0.

@@ -1030,7 +1027,10 @@ impl<'invocation, 'bs> Runtime for InvocationCtx<'invocation, 'bs> {
subinvocs.push(invoc);
subinvocs
});
res
Ok(Response {
exit_code: res.clone().map_or_else(|e| e.exit_code(), |_| ExitCode::OK),
Copy link
Member

@Stebalien Stebalien Jan 13, 2023

Choose a reason for hiding this comment

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

Suggested change
exit_code: res.clone().map_or_else(|e| e.exit_code(), |_| ExitCode::OK),
exit_code: res.as_ref().err().map(|e| e.exit_code()).unwrap_or(ExitCode::OK),

res
Ok(Response {
exit_code: res.clone().map_or_else(|e| e.exit_code(), |_| ExitCode::OK),
return_data: res.map_or_else(|mut e| e.take_data(), |r| r),
Copy link
Member

@Stebalien Stebalien Jan 13, 2023

Choose a reason for hiding this comment

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

Suggested change
return_data: res.map_or_else(|mut e| e.take_data(), |r| r),
return_data: res.unwrap_or_else(|mut e| e.take_data()),

@arajasek arajasek merged commit 2b1df24 into next Jan 13, 2023
@arajasek arajasek deleted the asr/runtime-errors branch January 13, 2023 04:35
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.

3 participants