Conversation
|
|
why not delete codeowners or rename the file? |
It had been commented out previously to keep around the original list of owners. I'm not married to this either way. |
Ok i'm not super opinionated, I have a slight preference for deleting it because it will likely go stale if its commented out |
FIxed. |
…RootAtTimestamp` (#2395) Closes #2383 , #2384 - Skipped testing for `supervisor_syncStatus` because that is being tested checking the chain progress. - Skipped `supervisor_dependencySetV1` because we need `QueryAPI` in Go implementation to implement the end-point so that we can test it using devstack. #### Changes - The serialize and deserialize implemented for `ChainID` is now generic for `u64` because I needed it at other places as well. - Due to the way Go unmarshalls the response, I needed to add the response objects `SuperRootOutputRpc` and `ChainRootInfoRpc`, which are essentially the same as `SuperRootOutput` and `ChainRootInfo` used before. The fields `timestamp`, `version` and `chainID` needed to be compatible with `hexutil.Uint64` and hexutil.Bytes`. Hence all the modifications. Tested locally, all tests including e2e tests are passing as expected.
…RootAtTimestamp` (op-rs/kona#2395) Closes #2383 , #2384 - Skipped testing for `supervisor_syncStatus` because that is being tested checking the chain progress. - Skipped `supervisor_dependencySetV1` because we need `QueryAPI` in Go implementation to implement the end-point so that we can test it using devstack. #### Changes - The serialize and deserialize implemented for `ChainID` is now generic for `u64` because I needed it at other places as well. - Due to the way Go unmarshalls the response, I needed to add the response objects `SuperRootOutputRpc` and `ChainRootInfoRpc`, which are essentially the same as `SuperRootOutput` and `ChainRootInfo` used before. The fields `timestamp`, `version` and `chainID` needed to be compatible with `hexutil.Uint64` and hexutil.Bytes`. Hence all the modifications. Tested locally, all tests including e2e tests are passing as expected.
2 participants
This PR adds support for Mergify, a tool that automates PR review. It uses a YAML file to define a set of review rules. The rules I've enabled for this repo are the following:
SR-RiskorC-Protocol-Criticalcan be auto-merged after a review from @maurelian or @tynes/@smartcontracts, respectively.SR-Riskreceive a comment asking for additional info on the shape of the security risk intorduced by the PR.C-Protocol-Criticallabel and request @tynes and @smartcontracts as reviewers.I've also removed
CODEOWNERSsince this replaces it.