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: appeals undetermined transactions #657

Open
wants to merge 38 commits into
base: main
Choose a base branch
from

Conversation

kstroobants
Copy link
Contributor

@kstroobants kstroobants commented Nov 28, 2024

Fixes #638

What

  • Added appeal window to undetermined state
  • Changed timestamp_accepted and added appeal_undetermined in database
  • Activated frontend button in undetermined state and added button also to modal
  • Leader only has no appeal button and no appeal window
  • Implemented the state transitions to process the appeal
  • Added test for leader appeals

Why

  • To add more value to the user

Testing done

  • tests/unit/consensus/test_base.py::test_exec_undetermined_appeal

Checks

  • I have tested this code
  • I have reviewed my own PR
  • I have created an issue for this PR
  • I have set a descriptive PR title compliant with conventional commits

Reviewing tips

  • Run simulator
  • Run test_exec_undetermined_appeal
  • Check code changes

- Add N+2 validators, remove leader
- Use latest data of transaction when in pending state and not the old one from the crawler
- Write consensus data before setting status to have it updated in frontend when going to transaction info modal
- Do not deploy contract when transaction was in the undetermined state
@kstroobants kstroobants self-assigned this Nov 28, 2024
@kstroobants kstroobants linked an issue Nov 28, 2024 that may be closed by this pull request
6 tasks
@kstroobants
Copy link
Contributor Author

@cristiam86 In the FinalizingState class we insert transactions from the transaction.consensus_data.leader_receipt.pending_transactions. Should this also happen when the status was UNDETERMINED (line 1229 in backend/consensus/base/py)? I believe not.

If you agree, I will add:
if context.transaction.status != TransactionStatus.UNDETERMINED:
# insert transactions

@cristiam86
Copy link
Collaborator

cristiam86 commented Dec 18, 2024

@cristiam86 In the FinalizingState class we insert transactions from the transaction.consensus_data.leader_receipt.pending_transactions. Should this also happen when the status was UNDETERMINED (line 1229 in backend/consensus/base/py)? I believe not.

If you agree, I will add: if context.transaction.status != TransactionStatus.UNDETERMINED: # insert transactions

@kstroobants We shouldn't emit messages when the transaction is undetermined. @kirilaa could you please confirm?

@kirilaa
Copy link

kirilaa commented Dec 18, 2024

@cristiam86 In the FinalizingState class we insert transactions from the transaction.consensus_data.leader_receipt.pending_transactions. Should this also happen when the status was UNDETERMINED (line 1229 in backend/consensus/base/py)? I believe not.
If you agree, I will add: if context.transaction.status != TransactionStatus.UNDETERMINED: # insert transactions

@kstroobants We shouldn't emit messages when the transaction is undetermined. @kirilaa could you please confirm?

true, the messages are emitted:

  • on acceptance
  • on finalization
  • now we had losely defined on finalization - imho we don't emit messages for finalized undetermined tx. That's from my side. Maybe I should double check with Edgars, but I am 95% we don't emit messages on finalized undetermined txs.

@kstroobants kstroobants marked this pull request as draft December 19, 2024 18:32
@kstroobants kstroobants marked this pull request as ready for review December 20, 2024 09:34
Copy link

Quality Gate Failed Quality Gate failed

Failed conditions
46.3% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

@@ -55,7 +56,7 @@ const handleSetTransactionAppeal = () => {
watch(
() => props.transaction.status,
(newStatus) => {
if (newStatus !== 'ACCEPTED') {
if (newStatus !== 'ACCEPTED' && newStatus !== 'UNDETERMINED') {
Copy link
Collaborator

Choose a reason for hiding this comment

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

@kstroobants what's the reason of this check? can't we rely in the appeal property of the transaction?

transaction = Transaction.from_dict(
transactions_processor.get_transaction_by_hash(transaction.hash)
)
await ConsensusAlgorithm(None, msg_handler_mock).exec_transaction(
Copy link
Collaborator

Choose a reason for hiding this comment

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

@kstroobants this seems like a different test, shouldn't we divide them into different ones?

Copy link
Collaborator

@cristiam86 cristiam86 left a comment

Choose a reason for hiding this comment

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

Minor comments that would be nice to solve

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Appeals: undetermined transactions
3 participants