-
Notifications
You must be signed in to change notification settings - Fork 467
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/timestamp block #2897
Feat/timestamp block #2897
Conversation
types/tipset_test.go
Outdated
@@ -153,7 +154,12 @@ func TestTipSet(t *testing.T) { | |||
// String shouldn't really need testing, but some existing code uses the string as a | |||
// datastore key and depends on the format exactly. | |||
assert.Equal(t, "{ "+b1.Cid().String()+" }", RequireNewTipSet(t, b1).String()) | |||
assert.Equal(t, "{ "+b1.Cid().String()+" "+b2.Cid().String()+" "+b3.Cid().String()+" }", | |||
|
|||
// DONOTMETGE the below assertion needed to be fixed after adding a timestamp to block. |
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.
@anorth could you confirm my suspicion here, blame shows you as the author. Does the order of these matter?
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.
Yes, order matters (from SortedCidSet)
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.
You can robustify the test by actually using a sortedcidset to order them.
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 fixed in #2908
fdbf911
to
1f59eee
Compare
Codecov Report
@@ Coverage Diff @@
## master #2897 +/- ##
========================================
Coverage ? 43%
========================================
Files ? 208
Lines ? 12370
Branches ? 0
========================================
Hits ? 5349
Misses ? 6211
Partials ? 810
|
plumbing/clock/testing.go
Outdated
import ( | ||
"time" | ||
|
||
"github.com/benbjohnson/clock" |
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 noticed from looking that the issues that this isn't actively maintained and has some open issues about races (they might actually be addressed but issues are open). Probably fine but something to keep in mind if we start seeing races in tests using it.
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.
Looks like the de-racing PR got closed down without merging and the author recommended this project: https://github.com/jonboulle/clockwork.
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.
Ohh nice find! I remember looking at that issue but didn't see the recommendation, will address and bubble up the changes to the validation branch.
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.
As mentioned in #2894, a clock should be fully independent of the blocktime configuration value, and will be used more widely. Unlike the configuration, I don't think the clock should be presented through plumbing (at least not yet). Just directly inject into the components that need it at construction (in node).
In chat I had questioned the use of an external dependency for this, but having inspected it a bit more this seems appropriate.
plumbing/clock/testing.go
Outdated
// NewMockBlockClock returns a new MockBlockClock with the provided blockTime. | ||
// Calls to MockBlockClock.EpochSeconds() will return 0 until a time is set using | ||
// the method SetClock(). | ||
func NewMockBlockClock(blkTime time.Duration) *MockBlockClock { |
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 suggest taking the mock time value in this constructor, saving most users a call to SetClock
1f59eee
to
1cc19ce
Compare
8ac5b9f
to
d14b976
Compare
b2caa77
to
3a5fe58
Compare
f676111
to
03af606
Compare
ac0d78c
to
acbcc58
Compare
03af606
to
def89fb
Compare
acbcc58
to
da4344d
Compare
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.
Looks good. I feel like with uint64 timestamps, it should be seconds since the big bang or something. Also, the description of this PR is incorrect, for future code-spelunkers.
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 would have expected to see this field being set by the block generation code, but trust that's coming real soon now.
What
This PR adds the timestamp field to block. This PR must be merged after #2914