-
Notifications
You must be signed in to change notification settings - Fork 77
Conversation
06b026c
to
e5e6e8e
Compare
e5e6e8e
to
29ad5b4
Compare
Nice! One thing I think is worth adding already on this first pass the |
chain/near.ts
Outdated
|
||
export class AccessKeyPermissionValue { | ||
constructor( | ||
public kind: AccessPermissionKind, |
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.
AccessPermissionKind
is not defined anywhere.
public kind: AccessPermissionKind, | |
public kind: AccessKeyPermissionKind, |
?
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're correct, just fixed the typo, thanks!
|
||
export class ExecutionOutcome { | ||
constructor( | ||
public proof: MerklePath, |
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.
MerklePath
is not defined anywhere
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.
Added! Nice catch 🙂
@maoueh thanks for the review! Still, two of your comments should've been caught by the CI, I'll investigate why it didn't failed compiling Edit: I've added a build step to the CI so that errors like these are caught early. I'm still not 100% sure why the tests didn't have a compilation error, but I guess it's a compiler optimization to remove dead code from the |
This is needed because of the `class MerklePath extends Array<MerklePathItem`. The same had to be done for `Tuple` and `Value` in the `ethereum` file/module. AssemblyScript requires those implementations because of the super class.
@otaviopace Missing pieces for
|
} | ||
} | ||
|
||
export class MerklePath extends Array<MerklePathItem> {} |
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.
Could we actually get rid of MerklePath
here, I'm not seeing the added benefits of having it. Maybe there is something else in play that I do not see.
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.
Do you want to remove the proof
field from the ExecutionOutcome
class entirely? It seems to be the only place that uses 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.
In fact, I'm wondering what is the correct Rust bindings for this one, is it AscPtr<AscMerklePath>
or directly AscPtr<Array<AsckMerklePathItem>>
?
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 we want to have the first one because it will be a new class, and that requires a new class identifier for the header.
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'll still wondering how such "extended" array should look like when generating the underlying AscMerklePath
here. How to represent the "extends" fact. Will need you help to determine the correct mapping.
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.
Left two more review comments.
chain/near.ts
Outdated
public outcomeRoot: CryptoHash, | ||
public chunksIncluded: u64, | ||
public challengesRoot: CryptoHash, | ||
public timestampNanosec: u64, |
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 the timestamp
is missing, this is, AFAIK, only the nano sec of the timestamp so it kind of add up to the timestamp
value in milliseconds (also to be validated) and adds extra precision.
We have the timestamp
in the protobuf.
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 didn't add because it's deprecated, as shown here: https://docs.rs/near-primitives/0.1.0-pre.1/near_primitives/views/struct.BlockHeaderView.html#structfield.timestamp
And we need to update for the latest |
The `test` script was not catching these for some reason that's probably related to how the AssemblyScript compiles code and removes unnecessary things (needs further investigation). For now it's very much helpful (and needed) to catch compilation errors on the CI step.
Ready for review, 🚨 don't merge 🚨 .
Based of the
Receipt
of this proto file.We probably will address the
TODO
comments once the.proto
file is up to date (which will require changes in multiple projects/repos, so that's for the end).Solves: https://github.com/graphprotocol/graph-ts/issues/209