Enable Cubist Signer integration #3965

geoff-vball · 2025-05-15T16:13:41Z

Why this should be merged

The enables the rpc-signer configuration.

This is based off of this old PR.

How this works

I moved the instantiation of the signer from the config package to node.New() where we instantiate everything else that needs filesystem/networking. This way we don't need to propagate cleanup all over the place.

I also opted for a Shutdown() method on bls.Signer, which is how the other resources attached to node are managed. Currently, resources are not shutdown if we fail in another part of node.New(), but this is how the rest of the resources are also managed.

Out of scope for this PR, but we may want to consider some sort of registry of cleanup/shutdown functions that can be unwound whenever we fail.

How this was tested

Unit tests

Need to be documented in RELEASES.md?

Yes?

The code was changed without changing the behaviour. Instead of `os.Stat`ing the file, we just try to read the file (which returned the same error type).

Prior to this, we were checking if the file existed before attempting to readd it. It was unnecessary and the logic has been removed.

… into signers-config-wip

config/config.go

node/signer.go

joshua-kim · 2025-07-02T20:50:37Z

node/signer_test.go

+	signer1, err := NewStakingSigner(config1.StakingSignerConfig)
+	require.NoError(err)
+	signer2, err := NewStakingSigner(config1.StakingSignerConfig)


This feels like we're testing implementation details, since this code is not a part of the public node api. I think we should just create the node through node.New, pass in the configuration, and do a check against the Signer exposed on it. If we do that I think these tests belong in node_test instead of in their own file, since we generally shouldn't test unexported code by calling it explicitly

I've simplified this test to hopefully make things more clear. What we're testing is that when a signer is created with a new key, that that key is saved and used the next time a signer is instantiated.

My concern isn't that the test is clear - it's that we're testing implementation details. ref #3965 (comment)

utils/crypto/bls/signer/rpcsigner/client.go

node/signer.go

joshua-kim · 2025-07-02T20:58:34Z

config/config_test.go

+func TestGetStakingSigner(t *testing.T) {
+	testKey := "HLimS3vRibTMk9lZD4b+Z+GLuSBShvgbsu0WTLt2Kd4="
+	testKeyPath1 := filepath.Join(t.TempDir(), ".avalanchego/staking/signer.key")
+	testKeyPath2 := strings.Replace(testKeyPath1, "001", "002", 1) // Anticipate the new temp dir that will be created


Is this safe to do? I think t.TempDir does clean up the dirs (so you can expect to start at 001), but if you hit power loss, a sig kill, or any other unexpected failure, this string replacement is brittle and can lead to flaky unit tests. It's also not documented as a guarantee on the interface for TempDir. Is it possible for us to get rid of this string matching?

I think t.TempDir creates an entirely new parent directory per test run, so should be unaffected by power-loss, panic etc, but I did find a way to remove the string replacement

I think it is still affected, since if the dir fails to cleanup the hard-coded string "001" would not match since testing will create a new dir with a unique name (ref).

In this case I'm fairly certain that testing will create an entirely new parent directory for the subsequent test run

joshua-kim · 2025-07-08T14:23:04Z

node/signer.go

Could we move this into node.go? Typically in Go it's idiomatic to put stuff close to where they're used, so creating flat file structures where you have a dedicated file/test-file per abstraction isn't common. I think it can be okay in some circumstances, but for a non-exported struct I would lean away from it.

node/signer.go

joshua-kim · 2025-07-08T14:33:12Z

node/signer_test.go

+	signer1, err := newStakingSigner(config)
+	require.NoError(err)
+	signer2, err := newStakingSigner(config)
+	require.NoError(err)


Since newStakingSigner is a non-exported helper, ideally we wouldn’t test it directly since it's an implementation detail of node, not a part of its api. Would it be possible to cover this logic by going through node.New instead? That would make the test more realistic and aligned with how the code is actually used by the caller.

Testing the idempotence of creating a "default signer" by creating an entire node seems completely antithetical to to idea of unit testing. I can push down the localsigner creation logic into an exported helper in localsigner if that makes the separation cleaner

Testing the idempotence of creating a "default signer" by creating an entire node seems completely antithetical to to idea of unit testing.

This is not exported as part of the package, so it's an implementation detail of the package api. I can be okay with testing un-exported code when:

The codebase is legacy and it is not reasonable for us to refactor code to test a change

There is an incident/sensitive timeframe

The abstraction being tested is clearly encapsulated and is non-trivial logic and it is also not possible to test through a public api

In this case, although this is well-encapsulated code, it is still possible to test through the public api if we parse default viper flags. My understanding is that it is possible and simple enough to test this through node.New and in exchange our test is less brittle and gives us better coverage. The way this bug would occur would be if someone spun up a node twice - why not reflect that in the test?

I can push down the localsigner creation logic into an exported helper in localsigner if that makes the separation cleaner

This is an option... but this initialization logic is only needed for the node since it needs to write/parse the key it generates on startup so it feels leaky to expose that api to all consumers of localsigner who only need it for unit tests.

joshua-kim · 2025-07-08T14:36:48Z

node/signer_test.go

Similar comment w.r.t Go file structure, but this should probably live in node_test as well.

Signed-off-by: Joshua Kim <20001595+joshua-kim@users.noreply.github.com>

geoff-vball · 2025-07-15T20:50:47Z

api/server/server.go

@@ -300,12 +301,13 @@ func (s *server) AddAliasesWithReadLock(endpoint string, aliases ...string) erro

 func (s *server) Shutdown() error {
 	ctx, cancel := context.WithTimeout(context.Background(), s.shutdownTimeout)
-	err := s.srv.Shutdown(ctx)
+	listenerErr := s.listener.Close()


This wasn't getting closed during node.Shutdown() which was causing an error starting up a new node in the same test.

Signed-off-by: Joshua Kim <20001595+joshua-kim@users.noreply.github.com>

StephenButtolph · 2025-07-16T16:57:27Z

node/node_test.go

+	v := setupViperFlags(t)
+	conf, err := config.GetNodeConfig(v)
+	require.NoError(err)


I don't think we should be creating a default node in unit tests.

Specifically, there are a number of default behaviors that aren't suitable for a unit test, such as:

Creating the ~/.avalanchego dir

populating it with a database

staking file

ect

opening servers at 9650, and 9651

When I run this test locally, it fails due to couldn't initialize API server: listen tcp 127.0.0.1:9650: bind: address already in use because I have a node running.

I really didn't want to 😅

Josh and I had conversations on this here and here. What would you suggest doing?

StephenButtolph · 2025-07-16T16:59:34Z

node/node.go

+func newStakingSigner(config any) (bls.Signer, error) {
+	switch cfg := config.(type) {


Why do we have multiple config types? We don't do this anywhere else afaik...

It's a downstream consequence of moving the instantiation of the signer from config to node.

config validates the config options and therefore knows what type of signer to instantiate and can pass the relevant information on. We could use config as just a translation layer between file and struct and move the validation logic to node, but that seemed like an even bigger change.

config/config_test.go

StephenButtolph · 2025-07-16T17:11:06Z

config/config_test.go

@@ -549,6 +551,95 @@ func TestGetSubnetConfigsFromFlags(t *testing.T) {
 	}
 }

+func TestGetStakingSigner(t *testing.T) {
+	testKey := "HLimS3vRibTMk9lZD4b+Z+GLuSBShvgbsu0WTLt2Kd4="
+	defaultSignerKeyTestDir := t.TempDir()


Can we call this the dataDir?

config/config_test.go

Co-authored-by: Stephen Buttolph <stephen@avalabs.org> Signed-off-by: Geoff Stuart <geoff.vball@gmail.com>

richardpringle and others added 30 commits March 12, 2025 14:05

Add comments to signer-config setup

dd5176e

Extend siging configuration to include RPC

ed0c5f8

Add default behaviour to switch

dd99c36

Add timeout to signer instantiation

9f61b1c

Make rpc-signer client handle the connection

f106e92

Fix linter error

de574a4

Close the connection on any error

a7e895a

Remove special character from error message

15a53f0

Use Go casing conventions in json config

cc11cac

Fix default signing config behaviour

eeb3644

Cleanup type-check in config-test

47e37fa

Simply variable name for url

505c7fb

Only use public config api in test

0d66c3a

Add test for default config signer with multiple inits

f8837e8

Merge remote-tracking branch 'origin/master' into signers-config-wip

97ffb21

Merge remote-tracking branch 'origin/master' into signers-config-wip

7327d0f

Bubble up cleanup function

bb56fd5

Merge remote-tracking branch 'origin/master' into signers-config-wip

0b22c0a

Merge remote-tracking branch 'origin/master' into signers-config-wip

d3e2677

Merge remote-tracking branch 'origin/master' into signers-config-wip

193ccd4

Simplify default signer creation code

bd77f88

The code was changed without changing the behaviour. Instead of `os.Stat`ing the file, we just try to read the file (which returned the same error type).

Cleanup signer creation when key path is set

5bc1bc0

Prior to this, we were checking if the file existed before attempting to readd it. It was unnecessary and the logic has been removed.

Remove redundant word in error message

64f1a1d

Fix config test name

b55f05d

Small rpc-signer-client cleanup refactor

e85e815

Fix the min-connect-timeout for grpc signer

c8b3714

Merge branch 'master' into signers-config-wip

c46209e

Merge branch 'master' into signers-config-wip

8a4cb7c

Reconfigure signer setup

99c3a48

Merge branch 'master' into signers-config-wip

e23e982

geoff-vball and others added 3 commits June 17, 2025 16:15

Merge branch 'signers-config-wip' of github.com:ava-labs/avalanche-go…

270d59a

… into signers-config-wip

Move signer to node package

60526b1

Merge branch 'master' into signers-config-wip

9791ff8

geoff-vball requested a review from joshua-kim June 17, 2025 20:25

geoff-vball and others added 4 commits June 18, 2025 10:54

Add missing files

ba4977a

Wrap error

3283340

Lint

d6512c2

Merge branch 'master' into signers-config-wip

3aaeda8

joshua-kim reviewed Jul 2, 2025

View reviewed changes

Review fixes

7018c21

geoff-vball requested a review from joshua-kim July 7, 2025 14:03

joshua-kim reviewed Jul 8, 2025

View reviewed changes

clean diff

945b7a1

Signed-off-by: Joshua Kim <20001595+joshua-kim@users.noreply.github.com>

joshua-kim force-pushed the signers-config-wip branch from b449826 to 945b7a1 Compare July 8, 2025 14:40

geoff-vball and others added 4 commits July 10, 2025 06:55

Merge branch 'master' into signers-config-wip

a178493

Defer cancel

931fb42

Move signer to node.go

bed4148

Merge branch 'master' into signers-config-wip

d07341b

geoff-vball commented Jul 15, 2025

View reviewed changes

geoff-vball requested a review from joshua-kim July 15, 2025 20:59

joshua-kim added 3 commits July 16, 2025 10:58

nits

b769bb0

Signed-off-by: Joshua Kim <20001595+joshua-kim@users.noreply.github.com>

remove env var

dc213df

Signed-off-by: Joshua Kim <20001595+joshua-kim@users.noreply.github.com>

style nits

872b353

Signed-off-by: Joshua Kim <20001595+joshua-kim@users.noreply.github.com>

joshua-kim approved these changes Jul 16, 2025

View reviewed changes

StephenButtolph reviewed Jul 16, 2025

View reviewed changes

geoff-vball and others added 4 commits July 16, 2025 14:47

Update config/config_test.go

8f15194

Co-authored-by: Stephen Buttolph <stephen@avalabs.org> Signed-off-by: Geoff Stuart <geoff.vball@gmail.com>

Update config/config_test.go

6170ab1

Co-authored-by: Stephen Buttolph <stephen@avalabs.org> Signed-off-by: Geoff Stuart <geoff.vball@gmail.com>

Update config/config_test.go

f33fbe7

Co-authored-by: Stephen Buttolph <stephen@avalabs.org> Signed-off-by: Geoff Stuart <geoff.vball@gmail.com>

dataDir

1dbf5dd

geoff-vball requested a review from StephenButtolph July 16, 2025 19:30

		func newStakingSigner(config any) (bls.Signer, error) {
		switch cfg := config.(type) {

Enable Cubist Signer integration #3965

Are you sure you want to change the base?

Enable Cubist Signer integration #3965

Uh oh!

Conversation

geoff-vball commented May 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why this should be merged

How this works

How this was tested

Need to be documented in RELEASES.md?

Uh oh!

Uh oh!

Uh oh!

joshua-kim Jul 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

joshua-kim Jul 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joshua-kim Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

geoff-vball commented May 15, 2025 •

edited

Loading

joshua-kim Jul 2, 2025 •

edited

Loading

joshua-kim Jul 2, 2025 •

edited

Loading

joshua-kim Jul 10, 2025 •

edited

Loading