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/timestamp block #2897

Merged
merged 1 commit into from
Jun 12, 2019
Merged

Feat/timestamp block #2897

merged 1 commit into from
Jun 12, 2019

Conversation

frrist
Copy link
Member

@frrist frrist commented Jun 6, 2019

What

This PR adds the timestamp field to block. This PR must be merged after #2914

@frrist frrist self-assigned this Jun 6, 2019
@@ -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.
Copy link
Member Author

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?

Copy link
Member

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)

Copy link
Member

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.

Copy link
Contributor

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

@frrist frrist force-pushed the feat/timestamp-block branch from fdbf911 to 1f59eee Compare June 6, 2019 17:06
@codecov-io
Copy link

codecov-io commented Jun 6, 2019

Codecov Report

❗ No coverage uploaded for pull request base (master@c15ebdd). Click here to learn what that means.
The diff coverage is 76%.

Impacted file tree graph

@@           Coverage Diff            @@
##             master   #2897   +/-   ##
========================================
  Coverage          ?     43%           
========================================
  Files             ?     208           
  Lines             ?   12370           
  Branches          ?       0           
========================================
  Hits              ?    5349           
  Misses            ?    6211           
  Partials          ?     810
Impacted Files Coverage Δ
protocol/storage/miner.go 23% <ø> (ø)
commands/daemon.go 0% <ø> (ø)
types/block.go 82% <ø> (ø)
node/node.go 59% <100%> (ø)
protocol/storage/client.go 48% <100%> (ø)
porcelain/protocol.go 46% <100%> (ø)
protocol/retrieval/client.go 23% <100%> (ø)
mining/worker.go 54% <25%> (ø)
consensus/expected.go 46% <50%> (ø)

@frrist frrist mentioned this pull request Jun 6, 2019
@frrist frrist requested review from anorth and ZenGround0 June 6, 2019 22:19
import (
"time"

"github.com/benbjohnson/clock"
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member

@anorth anorth left a 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.

// 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 {
Copy link
Member

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

@frrist frrist changed the base branch from feat/miner-worker-clock to feat/blocktime-porcelain June 12, 2019 17:09
@frrist frrist force-pushed the feat/timestamp-block branch from 1f59eee to 1cc19ce Compare June 12, 2019 17:15
@frrist frrist force-pushed the feat/blocktime-porcelain branch from 8ac5b9f to d14b976 Compare June 12, 2019 17:16
@frrist frrist force-pushed the feat/timestamp-block branch 2 times, most recently from b2caa77 to 3a5fe58 Compare June 12, 2019 17:26
@frrist frrist force-pushed the feat/blocktime-porcelain branch 2 times, most recently from f676111 to 03af606 Compare June 12, 2019 20:46
@frrist frrist force-pushed the feat/timestamp-block branch 2 times, most recently from ac0d78c to acbcc58 Compare June 12, 2019 20:55
@frrist frrist force-pushed the feat/blocktime-porcelain branch from 03af606 to def89fb Compare June 12, 2019 21:01
@frrist frrist changed the base branch from feat/blocktime-porcelain to master June 12, 2019 21:12
@frrist frrist force-pushed the feat/timestamp-block branch from acbcc58 to da4344d Compare June 12, 2019 21:13
@frrist frrist requested a review from ingar June 12, 2019 21:19
Copy link
Contributor

@ingar ingar left a 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.

@frrist frrist merged commit ebd469b into master Jun 12, 2019
Copy link
Member

@anorth anorth left a 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.

@ZenGround0 ZenGround0 deleted the feat/timestamp-block branch October 29, 2019 14:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants