-
Notifications
You must be signed in to change notification settings - Fork 456
Fix transaction related dependency - Closes #3614 #3620
Conversation
582ff25
to
c38f237
Compare
c38f237
to
7425530
Compare
… 3614-fix_transaction_related_dependency
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 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.
@@ -319,6 +307,53 @@ module.exports = class Chain { | |||
this.logger.info('Cleaned up successfully'); | |||
} | |||
|
|||
async _initModules() { |
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.
Can't we move all this logic to ./init_steps/init_modules
?
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.
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
I have separated |
}, | ||
channel, | ||
}; | ||
self = this; | ||
self.modules = { |
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.
Can we assign interfaceAdapters to a different variable name. Lest we will have self.modules
and module
variables which have different values.
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.
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, |
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.
Why do we bind transactionPool in the onBind function this file already receives it in the constructor?
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.
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
… 3614-fix_transaction_related_dependency
What was the problem?
Transaction related logic had dependency everywhere and logic was scattered.
How did I fix it?
transaction.js
and move API related logic to node status (only used for node status endpoint)How to test it?
Review checklist