Skip to content
This repository has been archived by the owner on Sep 20, 2023. It is now read-only.

Runlog service refactor tier 1 #139

Merged
merged 15 commits into from
Apr 26, 2021

Conversation

boxhock
Copy link
Contributor

@boxhock boxhock commented Apr 19, 2021

No description provided.

@boxhock boxhock force-pushed the runlog-service-refactor-tier-1 branch 2 times, most recently from 31d5675 to cc7a275 Compare April 20, 2021 15:21
@boxhock boxhock marked this pull request as ready for review April 21, 2021 10:29
Copy link
Contributor Author

@boxhock boxhock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is pretty big. The most important changes happen within subscriber and the ETH/EVM implementations in blockchain.

@@ -1,176 +0,0 @@
package blockchain
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deleted because the current ETH implementation would replace this now, so no need to maintain two exact identical implementations.

If there ever is a need to change the implementation for BSC, we can bring it back again.

Comment on lines +69 to +77
addresses := params.Addresses
if len(params.Addresses) == 0 && params.Address != "" {
addresses = []string{params.Address}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Helper to select a single address if possible

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about just always appending params.Address to addresses if it is not empty? Also, what is the case of having 2 separate fields?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We originally started by just having Addresses, but on the CL side it makes more sense to only define a single address: Address. Having support for both fields is more for backwards compatibility. Ideally, for more safety, I'd prefer users use the single address field.

@@ -5,7 +5,10 @@ import (
"errors"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not included in this tier, so can be ignored

Comment on lines -60 to +58
Request(t string) (response interface{}, err error)
Subscribe(ctx context.Context, t string, ch chan<- interface{}) (err error)
CreateJobRun(t string, v interface{}) (map[string]interface{}, error)
Stop()
}

type FluxMonitorManager interface {
Manager
GetState(ctx context.Context) (*FluxAggregatorState, error)
SubscribeEvents(ctx context.Context, ch chan<- interface{}) error
CreateJobRun(roundId uint32) map[string]interface{}
}

type RunlogManager interface {
Manager
SubscribeEvents(ctx context.Context, ch chan<- RunlogRequest) error
CreateJobRun(request RunlogRequest) map[string]interface{}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of having a very generic interface with a lot of interface{} types, I've split runlog and FM into two different interfaces, so they can be implemented more precisely and gives us more type safety.

@@ -1,20 +1,18 @@
package blockchain
package evm
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since a lot of blockchains are EVM based, having an EVM package allows other blockchains to import the common functionality that they need.

Comment on lines +10 to +12
"github.com/smartcontractkit/external-initiator/blockchain/common"

eth "github.com/ethereum/go-ethereum/common"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After going down a rabbit hole online, I've learned that dot-imports (which I had planned for our internal common package) is not a good thing to use, and should only ever be used in tests.

Instead, the GETH common package is imported as eth.

@boxhock boxhock requested a review from ebarakos April 21, 2021 10:42
Comment on lines +69 to +77
addresses := params.Addresses
if len(params.Addresses) == 0 && params.Address != "" {
addresses = []string{params.Address}
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about just always appending params.Address to addresses if it is not empty? Also, what is the case of having 2 separate fields?

RequestId string
CallbackFunction string
}
type RunlogRequest map[string]interface{}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why making it generic?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because all fields here ended up in what was previously the Params field anyways, so with the previous struct the values went a lot back-and-forth, and for new blockchain implementations, this list would just grow never ending.

"math/big"
"net/url"
"strings"
"time"

common2 "github.com/smartcontractkit/external-initiator/blockchain/common"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be renamed or maybe rename the geth package to eth as above?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be fixed once we reach this part of the migration

js := &store.JobSpec{
Job: req.JobID,
Spec: req.Params.FluxMonitor,
Spec: spec,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. So we are storing the whole actual JobSpec here, right? Both for RL and FM.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct

@@ -40,32 +40,32 @@ type FluxMonitorConfig struct {
func ParseFMSpec(jsonSpec json.RawMessage, runtimeConfig store.RuntimeConfig) (FluxMonitorConfig, error) {
var fmConfig FluxMonitorConfig

res := gjson.GetBytes(jsonSpec, "feeds.#.url")
res := gjson.GetBytes(jsonSpec, "fluxmonitor.feeds.#.url")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe keep only the fluxmonitor part before starting parsing? In order to not duplicate the fluxmonitor. below

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I initially wanted to do that, but wasn't able to get what I was looking for. Do you know how to do this with gjson?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like

jsonSpec = []byte(gjson.GetBytes(jsonSpec, "fluxmonitor").Raw)

or rename it to fmSpec

@@ -130,22 +130,16 @@ func NewFluxMonitor(job string, config FluxMonitorConfig, triggerJobRun chan sub

FAEvents := make(chan interface{})

state, err := fm.blockchain.Request(common.FMRequestState)
state, err := fm.blockchain.GetState(context.TODO())

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you envision this context.TODO() to be used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll define the request timeouts here, instead of having the blockchains define them. I'll make an issue for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

js, err := srv.store.LoadJobSpec(sub.Job)
if err != nil || js == nil {
if err != nil || gjson.GetBytes(js.Spec, "fluxmonitor").Raw == "null" {
startService = srv.subscribeRunlog

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not calling service, err := srv.subscribeRunlog(sub, triggerJobRun, js) here directly?

Instead of implementing Starter type etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, I'll change this.

@boxhock boxhock force-pushed the runlog-service-refactor-tier-1 branch from f6a5102 to 7495a92 Compare April 23, 2021 09:04
@boxhock boxhock requested a review from ebarakos April 23, 2021 09:14
@boxhock boxhock requested a review from ebarakos April 26, 2021 08:34
fmConfig.Multiply = int32(gjson.GetBytes(jsonSpec, "fluxmonitor.precision").Int())
fmConfig.Threshold = gjson.GetBytes(jsonSpec, "fluxmonitor.threshold").Float()
fmConfig.AbsoluteThreshold = gjson.GetBytes(jsonSpec, "fluxmonitor.absoluteThreshold").Float()
fmConfig.RequestData = fmSpec.Get("requestData").Raw

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@boxhock boxhock merged commit 4c6c7a8 into feature/fluxmonitor Apr 26, 2021
@boxhock boxhock deleted the runlog-service-refactor-tier-1 branch April 26, 2021 08:37
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants