Skip to content
This repository has been archived by the owner on Jun 11, 2024. It is now read-only.

Fix transaction related dependency - Closes #3614 #3620

Merged
merged 47 commits into from
May 24, 2019

Conversation

shuse2
Copy link
Collaborator

@shuse2 shuse2 commented May 14, 2019

What was the problem?

Transaction related logic had dependency everywhere and logic was scattered.

How did I fix it?

  • Transaction pool depends on blocks
  • blocks still temporally depends on transaction pool
  • removed proxy transaction.js and move API related logic to node status (only used for node status endpoint)
  • Removed dependency of blocks (_getCurrentContext) from process_transactions
  • Changed process transactions to function
  • Directly expose transaction pool as module
  • Skipped/replaced dapp related/using tests
  • Removed all callbacks in transactions and transaction pool

How to test it?

  • Run the application
  • Check the changed tests carefully
  • Run the tests

Review checklist

@shuse2 shuse2 changed the base branch from 3580_refactor_entry_modules to development May 15, 2019 04:15
@shuse2 shuse2 force-pushed the 3614-fix_transaction_related_dependency branch from 582ff25 to c38f237 Compare May 18, 2019 19:45
@shuse2 shuse2 force-pushed the 3614-fix_transaction_related_dependency branch from c38f237 to 7425530 Compare May 18, 2019 19:47
@shuse2 shuse2 marked this pull request as ready for review May 19, 2019 17:10
framework/src/modules/chain/loader.js Outdated Show resolved Hide resolved
framework/src/modules/chain/loader.js Show resolved Hide resolved
framework/src/modules/chain/transactions/votes.js Outdated Show resolved Hide resolved
@shuse2 shuse2 requested a review from SargeKhan May 23, 2019 06:54
Copy link
Contributor

@SargeKhan SargeKhan left a comment

Choose a reason for hiding this comment

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

I think there is a lack of consistency in the usage of transactions module in the application. In some cases we require the transaction module or some of it fuctions whereas in other cases, we use scope to initialize the module variable.
It leaves the responsibility to identify which parts of the module need to be imported and which parts need to be passed via scope to the coder. And this will lead to difficulty in understanding and inconsistency in one clearly defined approach to using modules.

framework/src/modules/http_api/controllers/node.js Outdated Show resolved Hide resolved
@@ -319,6 +307,53 @@ module.exports = class Chain {
this.logger.info('Cleaned up successfully');
}

async _initModules() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can't we move all this logic to ./init_steps/init_modules?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

we can move to the init_modules file, but it will not be dynamic anymore.
so probably it's easier to access all the required parameters here

@shuse2
Copy link
Collaborator Author

shuse2 commented May 23, 2019

I have separated transaction_manager to different folder and renamed it to interface_adapters/transaction_interface_adapter.js after discussion with @SargeKhan

},
channel,
};
self = this;
self.modules = {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we assign interfaceAdapters to a different variable name. Lest we will have self.modules and module variables which have different values.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

true, but this will be changed in the coming block PR

@@ -77,7 +77,7 @@ class Transport {
scope.config.nonce,
scope.config.broadcasts,
scope.config.forging.force,
scope.logic.transactionPool,
scope.modules.transactionPool,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we bind transactionPool in the onBind function this file already receives it in the constructor?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is because I didn't want to touch the bind method (since it will be removed), and it will break the test ='(
forgers, transport and loader needs to be refactored after the block PR

@shuse2 shuse2 requested a review from SargeKhan May 24, 2019 08:49
@shuse2 shuse2 merged commit 6899965 into development May 24, 2019
@shuse2 shuse2 deleted the 3614-fix_transaction_related_dependency branch June 8, 2019 10:20
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Combine all the transaction related logic into one module and expose used functionality
4 participants