Core/198/handle stale transactions #359
Conversation
Current coverage is 93.46% (diff: 95.83%)@@ master #359 diff @@
==========================================
Files 22 23 +1
Lines 1209 1254 +45
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 1118 1172 +54
+ Misses 91 82 -9
Partials 0 0
|
rhsimplex
force-pushed
the
core/198/handle-stale-transactions
branch
from
ef64c94
to
1da8950
Compare
rhsimplex
force-pushed
the
core/198/handle-stale-transactions
branch
3 times, most recently
from
cf939ee
to
6a774da
Compare
| @@ -70,6 +70,7 @@ def start(self): | |||
| p_map_bigchain.start() | |||
| logger.info('starting block') | |||
| block.start() | |||
| stale.start() | |||
|
Ok i don't know how to fix the test coverage. The only two untested lines left are the configuration. I've tried adding |
rhsimplex
force-pushed
the
core/198/handle-stale-transactions
branch
from
4bf52a0
to
8161495
Compare
| @@ -136,11 +138,54 @@ def write_transaction(self, signed_transaction, durability='soft'): | |||
| signed_transaction = deepcopy(signed_transaction) | |||
| # update the transaction | |||
| signed_transaction.update({'assignee': assignee}) | |||
| signed_transaction.update({'assignment_timestamp': time()}) | |||
There was a problem hiding this comment.
Instead of using time.time() maybe we should use bigchaindb.util.timestamp()
It should not make any difference in this case but I feel it would be more consistent and this would not break if in the future we change how federation nodes get their time
There was a problem hiding this comment.
Don't think it will work -- for stale transactions, we need to look within a window of time. A string time stamp may not order correctly (e.g. "100" comes before "20"). For instance, you can't call RethinkDBs between function on "0" and "140000000" and get the right answer, I believe.
There was a problem hiding this comment.
timestamp returns a fixed length string. You can always convert to int before writing it to the database. I am just concerned of problems that may arise if we start getting timestamps from different sources in different parts of the code
There was a problem hiding this comment.
Ok, then this shouldn't be too difficult
|
Another thing that is missing is that the block creation pipeline now needs to also listen for updates. |
# The first commit's message is: stale transaction monitor and tests # The 2nd commit message will be skipped: # simplify logic # The 3rd commit message will be skipped: # node will assign to self # The 4th commit message will be skipped: # block listens for insert and update # The 5th commit message will be skipped: # more test coverage # The 6th commit message will be skipped: # test coverage # The 7th commit message will be skipped: # test coverage
|
cc @vrde Two solutions would be:
|
rhsimplex
force-pushed
the
core/198/handle-stale-transactions
branch
from
51ce43f
to
84ccd01
Compare
|
works on my computer so I think we are good to go 👍 |
😂 |
* add timestamp to transaction assignment * add reassignment delay to configuration * refactor to multipipes * # This is a combination of 7 commits. # The first commit's message is: stale transaction monitor and tests # The 2nd commit message will be skipped: # simplify logic # The 3rd commit message will be skipped: # node will assign to self # The 4th commit message will be skipped: # block listens for insert and update # The 5th commit message will be skipped: # more test coverage # The 6th commit message will be skipped: # test coverage # The 7th commit message will be skipped: # test coverage * stale transaction monitor and tests * update operation only returns new value
addresses #198