refactor mercury #11137

shileiwill · 2023-11-01T05:18:57Z

AUTO-6853 AUTO-6327

Background

As said in the above tickets, The streamslookup code is not very modular and is difficult to import by other utilities (chaincli and observability). Refactor this codebase into a standalone package and remove the code duplication from chaincli.

Given that folks are actively working on mercury related improvements, I want to surface this PR early to get alignment and avoid missing important feature improvements (retry etc), and avoid conflicts.

This refactoring PR is on top of the core codebase as of 11/2. Some in-flight changes on mercury are not included, will need to add them manually, e.g. PR

As the saying goes, naming is one of the most difficult thing in programming, please suggest better names for folders and files if you have good names!

Shout out to @ferglor who laid the foundation for the big refactoring, thank you Fergal!

Description

Same as background

Changes

Break the streams_lookup.go to multiple components so it can be used as a lib.

Test Plans

PR is just to refactor current code without logic changes. All unit tests and integration tests should pass.
I ran smoke tests and unit tests locally to ensure they pass. Will wait for CI signals, should be all green.

github-actions · 2023-11-01T05:19:24Z

I see that you haven't updated any CHANGELOG files. Would it make sense to do so?

EasterTheBunny · 2023-11-03T14:00:00Z

core/services/ocr2/plugins/ocr2keeper/evm21/registry.go

@@ -122,14 +127,26 @@ var upkeepStateEvents = []common.Hash{
 }

 type MercuryConfig struct {
-	cred *models.MercuryCredentials
-	abi  abi.ABI
+	Cred *models.MercuryCredentials


If there is an accessor function, does this value need to be exported on the struct?

that is right, the Credentials() is more than enough, will update.

EasterTheBunny · 2023-11-03T14:01:19Z

core/services/ocr2/plugins/ocr2keeper/evm21/registry.go

+	AllowListCache *cache.Cache
+}
+
+func (c *MercuryConfig) Credentials() mercury.MercuryCredentials {


If you can, try not to return interfaces. It makes the code more brittle. The ideal Go pattern is to consume interfaces and return structs.

That is a trick used to avoid circular dependency. We have this models.MercuryCredentials struct defined in models package.

type MercuryCredentials struct { LegacyURL string URL string Username string Password string }

We then defined this mercury.MercuryCredentials interface under mercury package. models.MercuryCredentials implements mercury.MercuryCredentials so we can use mercury in all mercury related references, while keep the other non-mercury references unchanged.

I inherited this from Fergal. Happy to learn more on how we can improve.

EasterTheBunny · 2023-11-03T14:03:23Z

core/services/ocr2/plugins/ocr2keeper/evm21/registry_check_pipeline.go

@@ -101,7 +101,7 @@ func (r *EvmRegistry) getBlockHash(blockNumber *big.Int) (common.Hash, error) {
 }

 // verifyCheckBlock checks that the check block and hash are valid, returns the pipeline execution state and retryable
-func (r *EvmRegistry) verifyCheckBlock(_ context.Context, checkBlock, upkeepId *big.Int, checkHash common.Hash) (state encoding.PipelineExecutionState, retryable bool) {
+func (r *EvmRegistry) verifyCheckBlock(_ context.Context, checkBlock, upkeepId *big.Int, checkHash common.Hash) (state uint8, retryable bool) {


Here and many other places, a transition away from defined types to base types was done. Was there a reason for this? We lose some value of strong types in static code analysis when we do this.

It is also because of circular dependencies. The types are defined in encoding package, and we dont want to reference them from mercury packages. The UpkeepFailureReason is used by both mercury and non-mercury. Happy to hear other approaches.

type UpkeepFailureReason uint8 type PipelineExecutionState uint8

As part of the spike, it looked like the defined types were always explicitly cast to their underlying types before use, and we didn't seem to define any custom functions on the new types so it didn't feel necessary to keep the defined types at the time, but it's not something I feel strongly about either

+1 we should fix this, there's nothing stopping this function from returning a uint8 which is not a valid execution state. Plus as currently implemented there is duplication of definitions between mercury files and encoding files which is just a recipe for bugs

What's the correct dependency structure to do this properly?

FelixFan1992 · 2023-11-03T16:03:58Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/v02/request.go

+			c.lggr.Debugf("at block %s upkeep %s received status code %d from mercury v0.2 with BODY=%s", sl.Time.String(), sl.UpkeepId.String(), resp.StatusCode, hexutil.Encode(body))
+
+			var m MercuryV02Response
+			if err := json.Unmarshal(body, &m); err != nil {


since we are refactoring now, maybe let's use err1 here to avoid shadow?

I prefer shadowing err over err1, err2 etc

The golangci-lint configuration insists that you do not shadow. Is it failing to detect this case?

@jmank88 I dont see lint issues. Can I run golangci-lint locally? if so, i can try to repro.

This action is failing: https://github.com/smartcontractkit/chainlink/actions/runs/6791417403/job/18462870780#step:3:1

There is make golangci-lint for the core module. Not sure about the others but it could be adapted easily

FelixFan1992 · 2023-11-03T16:22:59Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/v03/request.go

+
+	ts := time.Now().UTC().UnixMilli()
+	signature := mercury.GenerateHMACFn(http.MethodGet, mercuryBatchPathV03+params, []byte{}, c.mercuryConfig.Credentials().GetUsername(), c.mercuryConfig.Credentials().GetPassword(), ts)
+	req.Header.Set("Content-Type", "application/json")


should we put these in some consts since they won't change?

shileiwill · 2023-11-03T21:40:04Z

core/services/ocr2/plugins/ocr2keeper/evm21/encoding/interface.go

 	ocr2keepers "github.com/smartcontractkit/ocr2keepers/pkg/v3/types"

 	"github.com/smartcontractkit/chainlink/v2/core/gethwrappers/generated/automation_utils_2_1"
 	iregistry21 "github.com/smartcontractkit/chainlink/v2/core/gethwrappers/generated/i_keeper_registry_master_wrapper_2_1"
 )

-type UpkeepFailureReason uint8
-type PipelineExecutionState uint8


Dug more on this. The root cause of circular dependency is the Packer interface. The old Packer interface is very convoluted. For mercury, we just need a subset of the functions, so we defined a smaller Packer for mercury in mercury.go.

type Packer interface { UnpackCheckCallbackResult(callbackResp []byte) (uint8, bool, []byte, uint8, *big.Int, error) PackGetUpkeepPrivilegeConfig(upkeepId *big.Int) ([]byte, error) UnpackGetUpkeepPrivilegeConfig(resp []byte) ([]byte, error) DecodeStreamsLookupRequest(data []byte) (*StreamsLookupError, error) }

The first return of UnpackCheckCallbackResult is a PipelineExecutionState. If we keep using this encoding. PipelineExecutionState, then mercury package will have encoding and encoding package will also need mercury.

type Packer interface { UnpackCheckCallbackResult(callbackResp []byte) (uint8, bool, []byte, uint8, *big.Int, error) ...

what's the plan to address this? We are causing a regression in typing

In order to extract Mercury as a standalone lib in this PR, we changed the return type of UnpackCheckCallbackResult func from encoding. PipelineExecutionState to uint8, so as to avoid circular dependency btw encoding and mercury.

IMHO, this encoding package can be refactored further. Those failure reasons and states can be in a standalone package, while packer in its own package. Packer has one-way invocation to the failure reason/states package.

FelixFan1992

from streams lookup logic perspective, i think everything looks OK so far.

ferglor · 2023-11-09T21:01:54Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/mercury.go

+		// if the core node has retried totalMediumPluginRetries times, do not set retry interval and plugin will use
+		// the default interval
+	} else {
+		ri = 1 * time.Second


Instead of this else block, you could change line 44 to beri := 1 * time.Second? Could we also rename ri to interval or retryInterval?

i renamed the variable. this else check should be here bc ok means contains or not...

ferglor · 2023-11-09T21:04:10Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/mercury_test.go

+	}
+
+	for _, tc := range testCases {
+		t.Run("", func(t *testing.T) {


Can we replace the empty string here with a tc.name field that describes what the test is doing?

FelixFan1992 · 2023-11-14T21:13:59Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/streams/streams.go

+
+	if failureReason == uint8(mercury.MercuryUpkeepFailureReasonMercuryCallbackReverted) {
+		checkResults[i].IneligibilityReason = uint8(mercury.MercuryUpkeepFailureReasonMercuryCallbackReverted)
+		s.lggr.Debugf("at block %d upkeep %s mercury callback reverts", lookup.Block, lookup.UpkeepId)


include time

FelixFan1992 · 2023-11-14T21:14:03Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/streams/streams.go

+
+	unpackCallBackState, needed, performData, failureReason, _, err := s.packer.UnpackCheckCallbackResult(mercuryBytes)
+	if err != nil {
+		s.lggr.Errorf("at block %d upkeep %s UnpackCheckCallbackResult err: %s", lookup.Block, lookup.UpkeepId, err.Error())


include time

FelixFan1992 · 2023-11-14T21:14:08Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/streams/streams.go

+
+	if !needed {
+		checkResults[i].IneligibilityReason = uint8(mercury.MercuryUpkeepFailureReasonUpkeepNotNeeded)
+		s.lggr.Debugf("at block %d upkeep %s callback reports upkeep not needed", lookup.Block, lookup.UpkeepId)


include time

ferglor · 2023-11-16T15:33:04Z

core/scripts/chaincli/handler/debug.go

@@ -227,6 +229,13 @@ func (k *Keeper) Debug(ctx context.Context, args []string) {
 		message(fmt.Sprintf("checkUpkeep failed with UpkeepFailureReason %d", checkResult.UpkeepFailureReason))
 	}
 	if checkResult.UpkeepFailureReason == uint8(encoding.UpkeepFailureReasonTargetCheckReverted) {
+		// TODO use the new streams lookup lib


Is this TODO still relevant?

This is still relevant, we are not actually using the new lib yet, this is gonna be the next PR.

ferglor · 2023-11-16T15:34:10Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/mercury_test.go

+			secret:   "yourSecret",
+			ts:       1234567890,
+			expected: "17b0bb6b14f7b48ef9d24f941ff8f33ad2d5e94ac343380be02c2f1ca32fdbd8",
+		},


Could we add more test cases here?

…est doesnt like using the registry contract directly

cl-sonarqube-production · 2023-11-16T17:16:07Z

SonarQube Quality Gate

0 Bugs
0 Vulnerabilities
0 Security Hotspots
3 Code Smells

81.0% Coverage
1.7% Duplication

infiloop2 · 2023-11-29T12:49:41Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/mercury.go

+func (l *StreamsLookup) IsMercuryUsingBatchPathV03() bool {
+	return l.TimeParamKey == BlockNumber
+}


shouldn't this also have a check for v03? (l.FeedParamKey == FeedIDs) since the time param key can be for v02 also

reading more, the context in which function is being is only for v0.3 so it doesn't cause any issue but function can be named better to reduce confusion

Yes, I am thinking of IsMercuryV03UsingBatchPath, let me know if you have a better name.

batch path is used in both v0.3 timestamp and block number. looking at the context https://github.com/smartcontractkit/chainlink/blob/develop/core/services/ocr2/plugins/ocr2keeper/evmregistry/v21/mercury/v03/request.go#L103-L105 maybe IsMercuryV03UsingBlockNumber ?

infiloop2 · 2023-11-29T12:57:15Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/upkeep_failure_reasons.go

+	// upkeep failure onchain reasons
+	MercuryUpkeepFailureReasonNone                    MercuryUpkeepFailureReason = 0
+	MercuryUpkeepFailureReasonTargetCheckReverted     MercuryUpkeepFailureReason = 3
+	MercuryUpkeepFailureReasonUpkeepNotNeeded         MercuryUpkeepFailureReason = 4
+	MercuryUpkeepFailureReasonMercuryCallbackReverted MercuryUpkeepFailureReason = 7
+	// leaving a gap here for more onchain failure reasons in the future
+	// upkeep failure offchain reasons
+	MercuryUpkeepFailureReasonMercuryAccessNotAllowed MercuryUpkeepFailureReason = 32
+	MercuryUpkeepFailureReasonInvalidRevertDataInput  MercuryUpkeepFailureReason = 34


how can we remove this duplication. This is just adding surface area for bugs when this file goes out of sync with interface file

How about we move the states/errors in interface file to a separate (standalone and light) package, so we can share states/errors across different services, mercury is one of the service referencing the states/errors?

possibly. looking at interface package, the circular dependency is because of DecodeStreamsLookupRequest(data []byte) (*mercury.StreamsLookupError, error)

Not sure if we can move to some mercury package to remove the cyclic dependency

infiloop2 · 2023-11-29T12:58:05Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/upkeep_states.go

+const (
+	NoPipelineError        MercuryUpkeepState = 0
+	RpcFlakyFailure        MercuryUpkeepState = 3
+	MercuryFlakyFailure    MercuryUpkeepState = 4
+	PackUnpackDecodeFailed MercuryUpkeepState = 5
+	MercuryUnmarshalError  MercuryUpkeepState = 6
+	InvalidMercuryRequest  MercuryUpkeepState = 7
+	InvalidMercuryResponse MercuryUpkeepState = 8 // this will only happen if Mercury server sends bad responses
+	UpkeepNotAuthorized    MercuryUpkeepState = 9
+)


same question as above

infiloop2 · 2023-11-30T19:32:14Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/mercury.go

+func (l *StreamsLookup) IsMercuryVersionUnkown() bool {
+	return l.FeedParamKey != FeedIDs
+}


this function is a bit confusing FeedParamKey can be FeedIdHex and not have unknown version

Agreed, I think we can remove this function. Looking at the usage, what we really need is to determine it is not v02 and not v03 (We can just use not IsMercuryV03())

yep sounds good

infiloop2 · 2023-11-30T19:45:21Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/streams/streams.go

+// buildResult checks if the upkeep is allowed by Mercury and builds a streams lookup request from the check result
+func (s *streams) buildResult(ctx context.Context, i int, checkResult ocr2keepers.CheckResult, checkResults []ocr2keepers.CheckResult, lookups map[int]*mercury.StreamsLookup) {
+	lookupLggr := s.lggr.With("where", "StreamsLookup")
+	if checkResult.IneligibilityReason != uint8(mercury.MercuryUpkeepFailureReasonTargetCheckReverted) {


this is a confusing constant, the ineligibility reason is generic target check reverted and not specific to mercury.

the revert data is what defines whether this revert was for mercury or not

I see. I guess a better representation could be "if checkResult.IneligibilityReason != uint8(encoding.UpkeepFailureReasonTargetCheckReverted)". This goes back to the package name discussion, where to hold the states and failureReasons.

infiloop2 · 2023-11-30T19:48:53Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/streams/streams.go

+			checkResults[i].IneligibilityReason = uint8(mercury.MercuryUpkeepFailureReasonMercuryAccessNotAllowed)
+			return
+		}
+	} else if streamsLookupResponse.IsMercuryVersionUnkown() {


as per current implementation this is not really an unknown check but a non v0.3 check

yes, true, will update.

infiloop2 · 2023-11-30T20:23:22Z

core/services/ocr2/plugins/ocr2keeper/evm21/block_subscriber.go

+func (bs *BlockSubscriber) LatestBlock() *ocr2keepers.BlockKey {
+	return bs.latestBlock.Load()
+}
+


i'm not sure why this change was needed. was this moved from somewhere?

This blockSubscriber is used in StreamsLookup, to be more precise, StreamsLookup uses only the latestBlock from blockSubscriber. This blockSubscriber is heavy and from a heavy package. we dont want to carry this to the new streams lib.

So, in this refactoring, streams takes a latestBlockProvider interface and requires implementation of LatestBlock function. Check streams.go L#71

Would like to hear if there is better way to achieve this.

sounds good

shileiwill · 2023-11-16T16:49:49Z

core/scripts/chaincli/handler/debug.go

@@ -227,6 +229,13 @@ func (k *Keeper) Debug(ctx context.Context, args []string) {
 		message(fmt.Sprintf("checkUpkeep failed with UpkeepFailureReason %d", checkResult.UpkeepFailureReason))
 	}
 	if checkResult.UpkeepFailureReason == uint8(encoding.UpkeepFailureReasonTargetCheckReverted) {
+		// TODO use the new streams lookup lib


This is still relevant, we are not actually using the new lib yet, this is gonna be the next PR.

shileiwill · 2023-12-02T05:26:25Z

core/services/ocr2/plugins/ocr2keeper/evm21/encoding/interface.go

 	ocr2keepers "github.com/smartcontractkit/ocr2keepers/pkg/v3/types"

 	"github.com/smartcontractkit/chainlink/v2/core/gethwrappers/generated/automation_utils_2_1"
 	iregistry21 "github.com/smartcontractkit/chainlink/v2/core/gethwrappers/generated/i_keeper_registry_master_wrapper_2_1"
 )

-type UpkeepFailureReason uint8
-type PipelineExecutionState uint8


In order to extract Mercury as a standalone lib in this PR, we changed the return type of UnpackCheckCallbackResult func from encoding. PipelineExecutionState to uint8, so as to avoid circular dependency btw encoding and mercury.

IMHO, this encoding package can be refactored further. Those failure reasons and states can be in a standalone package, while packer in its own package. Packer has one-way invocation to the failure reason/states package.

shileiwill · 2023-12-02T05:33:55Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/mercury.go

+func (l *StreamsLookup) IsMercuryUsingBatchPathV03() bool {
+	return l.TimeParamKey == BlockNumber
+}


Yes, I am thinking of IsMercuryV03UsingBatchPath, let me know if you have a better name.

shileiwill · 2023-12-02T05:37:12Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/upkeep_failure_reasons.go

+	// upkeep failure onchain reasons
+	MercuryUpkeepFailureReasonNone                    MercuryUpkeepFailureReason = 0
+	MercuryUpkeepFailureReasonTargetCheckReverted     MercuryUpkeepFailureReason = 3
+	MercuryUpkeepFailureReasonUpkeepNotNeeded         MercuryUpkeepFailureReason = 4
+	MercuryUpkeepFailureReasonMercuryCallbackReverted MercuryUpkeepFailureReason = 7
+	// leaving a gap here for more onchain failure reasons in the future
+	// upkeep failure offchain reasons
+	MercuryUpkeepFailureReasonMercuryAccessNotAllowed MercuryUpkeepFailureReason = 32
+	MercuryUpkeepFailureReasonInvalidRevertDataInput  MercuryUpkeepFailureReason = 34


How about we move the states/errors in interface file to a separate (standalone and light) package, so we can share states/errors across different services, mercury is one of the service referencing the states/errors?

shileiwill · 2023-12-02T05:40:59Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/mercury.go

+func (l *StreamsLookup) IsMercuryVersionUnkown() bool {
+	return l.FeedParamKey != FeedIDs
+}


Agreed, I think we can remove this function. Looking at the usage, what we really need is to determine it is not v02 and not v03 (We can just use not IsMercuryV03())

shileiwill · 2023-12-02T05:45:11Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/streams/streams.go

+			checkResults[i].IneligibilityReason = uint8(mercury.MercuryUpkeepFailureReasonMercuryAccessNotAllowed)
+			return
+		}
+	} else if streamsLookupResponse.IsMercuryVersionUnkown() {


yes, true, will update.

shileiwill · 2023-12-02T05:49:43Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/streams/streams.go

+	}
+
+	if block == nil || block.Int64() == 0 {
+		if latestBlock := s.blockSubscriber.LatestBlock(); latestBlock != nil && latestBlock.Number != 0 {


LatestBlock() is used in this buildCallOpts function. This is part of blockSubscriber.

shileiwill · 2023-12-02T05:51:17Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/streams/streams.go

+	}
+
+	if block == nil || block.Int64() == 0 {
+		if latestBlock := s.blockSubscriber.LatestBlock(); latestBlock != nil && latestBlock.Number != 0 {


LatestBlock() is used in buildCallOpts(). This is part of blockSubscriber.

shileiwill · 2023-12-02T05:53:17Z

core/services/ocr2/plugins/ocr2keeper/evm21/mercury/streams/streams.go

+func NewStreamsLookup(
+	packer mercury.Packer,
+	mercuryConfig mercury.MercuryConfigProvider,
+	blockSubscriber latestBlockProvider,


To get rid of the dependency of blockSubscriber, we created this latestBlockProvider interface, which requires latestBlock() func. This latestBlock func is the only func we need in streamsLookup.

Also refer to streams.go L#310

shileiwill · 2023-12-02T05:57:30Z

core/services/ocr2/plugins/ocr2keeper/evm21/block_subscriber.go

+func (bs *BlockSubscriber) LatestBlock() *ocr2keepers.BlockKey {
+	return bs.latestBlock.Load()
+}
+


This blockSubscriber is used in StreamsLookup, to be more precise, StreamsLookup uses only the latestBlock from blockSubscriber. This blockSubscriber is heavy and from a heavy package. we dont want to carry this to the new streams lib.

So, in this refactoring, streams takes a latestBlockProvider interface and requires implementation of LatestBlock function. Check streams.go L#71

Would like to hear if there is better way to achieve this.

shileiwill force-pushed the refactor_mercury branch 5 times, most recently from 5b63dd7 to 81f9647 Compare November 3, 2023 07:33

shileiwill marked this pull request as ready for review November 3, 2023 07:48

shileiwill requested review from a team, jmank88 and krehermann as code owners November 3, 2023 07:48

shileiwill requested review from a team and removed request for a team November 3, 2023 07:48

EasterTheBunny reviewed Nov 3, 2023

View reviewed changes

FelixFan1992 reviewed Nov 3, 2023

View reviewed changes

shileiwill force-pushed the refactor_mercury branch from 81f9647 to 049178c Compare November 3, 2023 21:34

shileiwill commented Nov 3, 2023

View reviewed changes

shileiwill force-pushed the refactor_mercury branch 7 times, most recently from b8051e8 to a73e8eb Compare November 8, 2023 21:33

FelixFan1992 reviewed Nov 9, 2023

View reviewed changes

shileiwill requested review from EasterTheBunny, FelixFan1992 and ferglor November 9, 2023 17:03

ferglor reviewed Nov 9, 2023

View reviewed changes

FelixFan1992 reviewed Nov 14, 2023

View reviewed changes

shileiwill force-pushed the refactor_mercury branch 2 times, most recently from fd1a4e0 to 880e7be Compare November 15, 2023 17:35

ferglor reviewed Nov 16, 2023

View reviewed changes

shileiwill force-pushed the refactor_mercury branch from 880e7be to 347fd35 Compare November 16, 2023 17:03

shileiwill added 5 commits November 16, 2023 09:04

refactor mercury, rebase on top of PR 10878

4fb93a7

change back to use eth_call, sigh, simulated backend in integration t…

9865e6b

…est doesnt like using the registry contract directly

fixes and include new threadctl changes

ec3b511

address comments, add time in logs

0b3a28c

rebase and add a test

bb160e2

shileiwill force-pushed the refactor_mercury branch from 347fd35 to bb160e2 Compare November 16, 2023 17:04

anirudhwarrier approved these changes Nov 16, 2023

View reviewed changes

shileiwill added this pull request to the merge queue Nov 16, 2023

Merged via the queue into develop with commit e030073 Nov 16, 2023
88 of 89 checks passed

shileiwill deleted the refactor_mercury branch November 16, 2023 18:26

infiloop2 reviewed Nov 29, 2023

View reviewed changes

infiloop2 reviewed Nov 30, 2023

View reviewed changes

shileiwill commented Dec 2, 2023

View reviewed changes

shileiwill mentioned this pull request Dec 5, 2023

small improvements based on comments #11491

Merged

snehaagni mentioned this pull request Jan 24, 2024

release/2.8.0 -> master #11883

Merged

refactor mercury #11137

refactor mercury #11137

Conversation

shileiwill commented Nov 1, 2023 • edited Loading

Background

Description

Changes

Test Plans

github-actions bot commented Nov 1, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

infiloop2 Nov 29, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

FelixFan1992 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cl-sonarqube-production bot commented Nov 16, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

infiloop2 Nov 30, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shileiwill commented Nov 1, 2023 •

edited

Loading

infiloop2 Nov 29, 2023 •

edited

Loading

infiloop2 Nov 30, 2023 •

edited

Loading