-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Make state tipset usage consistent in the API #4545
Conversation
The test failures look problematic. (resolved) |
21e13ef
to
c6a7c6d
Compare
@@ -144,20 +144,6 @@ func MinerSectorInfo(ctx context.Context, sm *StateManager, maddr address.Addres | |||
return mas.GetSector(sid) | |||
} | |||
|
|||
func GetMinerSectorSet(ctx context.Context, sm *StateManager, ts *types.TipSet, maddr address.Address, snos *bitfield.BitField) ([]*miner.SectorOnChainInfo, error) { |
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 was a drive-by fix. Removed because it was only being used in one place at this point.
err error | ||
} | ||
|
||
type cachedActorLookup struct { |
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.
dead code
@@ -109,7 +108,7 @@ func (a *StateAPI) StateMinerActiveSectors(ctx context.Context, maddr address.Ad | |||
return nil, xerrors.Errorf("merge partition active sets: %w", err) | |||
} | |||
|
|||
return stmgr.GetMinerSectorSet(ctx, a.StateManager, ts, maddr, &activeSectors) | |||
return mas.LoadSectors(&activeSectors) |
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 avoids loading the actor twice.
The tests pass but there are still outstanding questions. |
3188820
to
0b37dda
Compare
1.2.1 is probably the right release for this, after careful review and letting it run on our nodes for a while |
0b37dda
to
6d1ac1e
Compare
_Always_ (almost) use the tipset's parent state, instead of computing. Exceptions: * MinerGetBaseInfo. Fixing this would break things so we need to be careful (although we could bump the API version, fix it, then fix the call sites). * StateReplay. This is replaying a message on top of the given tipset. * GasEstimateGasLimit. This executes the message on-top-of the tipset's computed state (unlike call which executes it on the tipset's parent state). * Having this method and Call apply the message at different heights is really weird.
… the tipset We could also do this in the message pool itself, but I'm not sure if it's worth it?
StateGetActor now gets the actor at the tipset parent state.
6d1ac1e
to
b78b9a4
Compare
…stent-tipset-methods
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.
Would be nice to finally land this.
Not entirely sure why, but tests fail on latest master with this
return act.Nonce, nil | ||
for _, msg := range msgs { | ||
vmmsg := msg.VMMessage() | ||
if vmmsg.From != keyAddr { |
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 msg.From can technically also be an ID address, though I don't see messages like that on-chain
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 sure? It looks like message verification will fail if the from address is not a public key.
lotus/chain/messagepool/messagepool.go
Lines 635 to 637 in 4937fb9
if err := sigs.Verify(&m.Signature, m.Message.From, m.Message.Cid().Bytes()); err != nil { | |
return err | |
} |
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.
Uff we should fix 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.
yeah, you should abosolutely be able to send a message with an ID address as the from
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.
Well, we can add that to the network upgrade. Note: we'll need to carefully check the VM to make sure we resolve everything as expected before passing it off to the actors.
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.
Note: we currently implicitly resolve the from address when sending. Should we not be doing that?
Co-authored-by: Łukasz Magiera <magik6k@users.noreply.github.com>
…stent-tipset-methods
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. Also did some manual testing and everything appears to work well
…efactor-consistent-tipset-methods Make state tipset usage consistent in the API
Always (almost) use the tipset's parent state, instead of computing.
Exceptions: