-
Notifications
You must be signed in to change notification settings - Fork 31
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
Refactor transaction result code #77
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few minor things mentioned above.
Would also prefer checking mergability with the VM branch, as it looks like it will create some conflicts on merge.
@@ -742,13 +742,13 @@ protected Block proposeBlock() { | |||
long t1 = TimeUtil.currentTimeMillis(); | |||
|
|||
// fetch pending transactions | |||
final List<PendingManager.PendingTransaction> pending = pendingMgr | |||
final List<PendingManager.EvaluatedTransaction> pending = pendingMgr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For VM calls, I'm not sure that 'evaluatedTransaction' really describes their state at this point. They've been checked for only the most minimal of validation, since we cannot do the same early validation as we do as basic transaction types.
break; | ||
} | ||
if (value.lt(config.minDelegateBurnAmount())) { | ||
result.setError(Error.INVALID_DELEGATE_BURN_AMOUNT); | ||
result.setCode(Code.INVALID_BURNING_AMOUNT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I prefer keeping Delegate in the code variable name, since the act they're doing is registering a delegate, the burning is just a side effect.
return this == FAILURE; | ||
} | ||
|
||
public boolean isAccepted() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's strange to have isAccepted() and isRejected()
Would suggest at minimum to make isAccepted() return !isRejected() or vice versa, rather than have 2 separate implementations for maintenance purposes.
No description provided.