Skip to content
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

Only encode non nil block numbers #13726

Merged
merged 6 commits into from
Jul 2, 2024
Merged

Only encode non nil block numbers #13726

merged 6 commits into from
Jul 2, 2024

Conversation

ferglor
Copy link
Collaborator

@ferglor ferglor commented Jul 1, 2024

AUTO-11111

The node upgrade test for automation 2.0 was panicking due to a nil block number; this PR modifies buildCallOpts to allow for block 0 to be specified, in order to prevent a nil pointer.

Node upgrade test passing here: https://github.com/smartcontractkit/chainlink/actions/runs/9746647010

@ferglor ferglor requested a review from a team as a code owner July 1, 2024 12:56
@@ -716,7 +716,7 @@ func (r *EvmRegistry) getUpkeepConfigs(ctx context.Context, ids []*big.Int) ([]a
)

for i, id := range ids {
opts, err := r.buildCallOpts(ctx, nil)
opts, err := r.buildCallOpts(ctx, big.NewInt(0))
Copy link
Contributor

Choose a reason for hiding this comment

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

should this change be done within buildCallOpts so that if other services are using the function they don't get a nil pointer?

maybe just the if condition in line 469 can be removed

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe! I wanted to see what happens with just this change so far; buildCallOpts has been updated to initialise with whatever block we pass rather than directly with nil, and I wanted to limit the change for now so that we pass a non-nil value here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm working off the assumption that specifying block 0 actually means the latest block is used - is that correct?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@ferglor ferglor changed the title Specify block 0 instead of nil Allow block 0 to prevent nil pointer Jul 1, 2024
@ferglor ferglor requested a review from a team as a code owner July 1, 2024 15:27
Copy link
Contributor

@infiloop2 infiloop2 left a comment

Choose a reason for hiding this comment

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

did we check what eth calls do when 0 is passed as block number?

if r.LatestBlock() != 0 {
opts.BlockNumber = big.NewInt(r.LatestBlock())
}
opts.BlockNumber = big.NewInt(r.LatestBlock())
Copy link
Contributor

Choose a reason for hiding this comment

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

actually i see this function can also return an error. Maybe it makes more sense to return an error instead of setting it to 0?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In the CallOpts struct, BlockNumber is documented as optional - should we be erroring when trying to set an optional field? Maybe as an alternative, we shouldn't change this function, and only set the optional BlockNumber arg on eth_call when opts.BlockNumber is non-nil?

Copy link
Contributor

@infiloop2 infiloop2 Jul 1, 2024

Choose a reason for hiding this comment

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

oh interesting. BlockNumber is documented as optional . Does nil not qualify as optional? or is it different than not setting this field at all, something like

	opts := bind.CallOpts{
		Context:     ctx,
	}

Copy link
Collaborator Author

@ferglor ferglor Jul 1, 2024

Choose a reason for hiding this comment

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

So the problem is that we're passing a nil value to hexutil.EncodeBig, i.e. hexutil.EncodeBig(opts.BlockNumber). So I was thinking of changing this:

checkReqs[i] = rpc.BatchElem{
	Method: "eth_call",
	Args: []interface{}{
		map[string]interface{}{
			"to":   r.addr.Hex(),
			"data": hexutil.Bytes(payload),
		},
		hexutil.EncodeBig(opts.BlockNumber),
	},
	Result: &result,
}

To something like this:

args := []interface{}{
  map[string]interface{}{
	  "to":   r.addr.Hex(),
	  "data": hexutil.Bytes(payload),
  }}

if opts.BlockNumber != nil {
    args = append(args, hexutil.EncodeBig(opts.BlockNumber)
}

checkReqs[i] = rpc.BatchElem{
	Method: "eth_call",
	Args: args,
	Result: &result,
}

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah i think that makes sense. We'll need to do it in all places where args are made?

@ferglor ferglor changed the title Allow block 0 to prevent nil pointer Only encode non nil block numbers Jul 2, 2024
infiloop2
infiloop2 previously approved these changes Jul 2, 2024
@ferglor ferglor enabled auto-merge July 2, 2024 11:24
@ferglor ferglor added this pull request to the merge queue Jul 2, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jul 2, 2024
@ferglor ferglor added this pull request to the merge queue Jul 2, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jul 2, 2024
@ferglor ferglor added this pull request to the merge queue Jul 2, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jul 2, 2024
@ferglor ferglor added this pull request to the merge queue Jul 2, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jul 2, 2024
@ferglor ferglor added this pull request to the merge queue Jul 2, 2024
Merged via the queue into develop with commit 2ecf45d Jul 2, 2024
112 checks passed
@ferglor ferglor deleted the spike/nil-pointer-cla-20 branch July 2, 2024 13:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants