lighthouse icon indicating copy to clipboard operation
lighthouse copied to clipboard

GET fee recipient (key manager API) always returns the default one even if a new one was already set

Open jvbriones opened this issue 3 years ago • 4 comments

Description

After a POST for a {pubkey} with a new fee recipient value (via Key manager API) we can check that the new value is properly saved in the validator_definitions.yml file. Nonetheless, the next time requesting GET for the same {pubkey} LightHouse returns the default fee recipient value (set at startup with --suggested-fee-recipient).

Version

docker - v2.5.1-modern

Present Behaviour

GET /eth/v1/validator/{pubkey}/feerecipient It always returns the default --suggested-fee-recipient value even if a new one was already set for {pubkey}.

Expected Behaviour

To return the suggested_fee_recipient value set for the given {pubkey} already saved in validator_definitions.yml.

jvbriones avatar Aug 11 '22 16:08 jvbriones

I can't reproduce this issue. When I make a POST request to set the fee recipient it gets reflected in the GET request and is written to the validator_defintions.yml.

The commands I used to test this were:

POST:

curl -X POST --data '{"ethaddress": "0x0000000000000000000000000000000000000000"}' -H "Content-Type: application/json" -H "Authorization: Bearer $(cat ~/.lighthouse/prater/validators/api-token.txt)" "http://localhost:5062/eth/v1/validator/0x80f4b7f663a385eccbffeccdb13592111cd4e82c0ebb24e5902a4546034e97d0ee039ae6845f571e6aca8f1f861f7faf/feerecipient"

and then GET

curl -s -H "Authorization: Bearer $(cat ~/.lighthouse/prater/validators/api-token.txt)" "http://localhost:5062/eth/v1/validator/0x80f4b7f663a385eccbffeccdb13592111cd4e82c0ebb24e5902a4546034e97d0ee039ae6845f571e6aca8f1f861f7faf/feerecipient" | jq
{
  "data": {
    "pubkey": "0x80f4b7f663a385eccbffeccdb13592111cd4e82c0ebb24e5902a4546034e97d0ee039ae6845f571e6aca8f1f861f7faf",
    "ethaddress": "0x0000000000000000000000000000000000000000"
  }
}

meanwhile my lighthouse vc is running using a different address for the --suggested-fee-recipient default:

./lighthouse vc \
	--network prater \
	--graffiti "lighthouse-nethermind-infura" \
	--http \
	--http-allow-origin '*' \
	--suggested-fee-recipient "0xaEBBc82507Ec0aD78e2BF285077B7c38F23B7F83"

Are you sure that your POST request isn't failing?

michaelsproul avatar Aug 16 '22 02:08 michaelsproul

The POST is working fine (202) and saving into the validator_defintions.yml the given fee recipient config.

The problem seems to be with the GET when having more than one validator configured. It only returns properly the first entry, for the rest pubkeys it always returns the default --suggested-fee-recipient value.

Please try it out again with several pubkeys configured in validator_definitions.yml.

jvbriones avatar Aug 16 '22 08:08 jvbriones

The POST is working fine (202) and saving into the validator_defintions.yml the given fee recipient config.

The problem seems to be with the GET when having more than one validator configured. It only returns properly the first entry, for the rest pubkeys it always returns the default --suggested-fee-recipient value.

Please try it out again with several pubkeys configured in validator_definitions.yml.

@jvbriones The POST request has the PUBKEY as part of the URL because the request applies only to that specific PUBKEY. This is the expected behavior:

  • GET PUBKEY1
  • default

  • GET PUBKEY2
  • default

  • GET PUBKEY3
  • default

  • POST PUBKEY2 FEE_RECIPIENT2
  • null

  • GET PUBKEY2
  • FEE_RECIPIENT2

  • GET PUBKEY3
  • default

  • POST PUBKEY3 FEE_RECIPIENT3
  • null

  • GET PUBKEY3
  • FEE_RECIPIENT3

  • GET PUBKEY1
  • default

and I confirmed this behavior with Lighthouse v2.5.1-4fc0cb1

ethDreamer avatar Aug 16 '22 17:08 ethDreamer

This issue could be related with my local env (Mac M1). The 2.5.1 version deployed in our dev environment it's working as expected. No idea why is not working for me, but from this point on, I will share my findings in case it helps. If it's not reproducible anymore I guess we better close it.


The POST request has the PUBKEY as part of the URL because the request applies only to that specific PUBKEY.

Yes, the POST has been always working fine. The issue is related with the GET, since is not returning the new given value already saved in validator_defintions.yml after a POST request. It still happening to me, and tried again for both docker version (latest-arm) and latest 2.5.1 binary. Observed behaviours:

FEE_RECIPIENT2 = 0x0000000000000000000000000000000000000000

./lighthouse vc \
--network prater \
--http \
--http-allow-origin '*' \
--suggested-fee-recipient "0xd50....." \
--unencrypted-http-transport \
--http-address "0.0.0.0"

GET PUBKEY1

default (0xd50....)

GET PUBKEY2

default (0xd50....)

POST PUBKEY2 FEE_RECIPIENT2 -> (returns 202, and also add the new value (0x000..) in suggested_fee_recipient for PUBKEY2 entry in validator_defintions.yml)

null

GET PUBKEY2

default (0xd50....)

Sometimes the GET was working fine just for the first entry PUBKEY1. In another try, also happened that after a single POST request for a specific PUBKEY, all the others PUBKEYS entries were as well updated with previous used values for their suggested_fee_recipient in validator_defintions.yml, like a batch operation. I wonder if is due a kind of cache that is acting in between or due a not fully synced EL or CL.

jvbriones avatar Aug 18 '22 09:08 jvbriones