feat: send epoch number on each request

[Ansonhkg]

Description

Send epoch number on each request.

eg. output:

[Lit-JS-SDK v3.2.1] [2024-02-21T05:54:11.528Z] [DEBUG] [core] [id: 53465468198df] sendCommandToNode with url https://cayenne.litgateway.com:7371/web/execute and data {
  authSig: {
    sig: '0xcf98137cd6a0770463ec0023848c552601f6ae1a18034a0264df1cff4f5997901281ddc9bda1866ec1ae69a735889174398526fa2af6302223e0f520b1bf614f1b',
    derivedVia: 'web3.eth.personal.sign',
    signedMessage: 'localhost wants you to sign in with your Ethereum account:\n' +
      '0xeF71c2604f17Ec6Fc13409DF24EfdC440D240d37\n' +
      '\n' +
      'This is a test statement.  You can put anything you want here.\n' +
      '\n' +
      'URI: https://localhost/login\n' +
      'Version: 1\n' +
      'Chain ID: 1\n' +
      'Nonce: 0x58ecdc1927f9d2bdf265a54a29aaa2b9fe93c2ec32b4d85a1b5b605627fa5dc2\n' +
      'Issued At: 2024-02-21T01:42:45.604Z\n' +
      'Expiration Time: 2024-02-21T02:42:45.601Z',
    address: '0xeF71c2604f17Ec6Fc13409DF24EfdC440D240d37'
  },
  code: 'KGFzeW5jICgpID0+IHsKICAgICAgY29uc3Qgc2lnU2hhcmUgPSBhd2FpdCBMaXRBY3Rpb25zLnNpZ25FY2RzYSh7CiAgICAgICAgdG9TaWduOiBkYXRhVG9TaWduLAogICAgICAgIHB1YmxpY0tleSwKICAgICAgICBzaWdOYW1lOiAic2lnIiwKICAgICAgfSk7CiAgICB9KSgpOw==',
  ipfsId: undefined,
  jsParams: {
    dataToSign: [
      125, 135, 197, 234, 117, 247,  55, 139,
      183,   1, 228,   4, 197,   6,  57,  22,
       26, 243, 239, 246,  98, 147, 233, 243,
      117, 181, 241, 126, 181,   4, 118, 244
    ],
    publicKey: '04b5caf00c9f5adc9b22ca460b88482bad44ed4fac8ee63014b727cf60efc568dbdfe498a94fbd9cd294d651529f9fe76e057e9736150eea038415b06f64a87939'
  },
  authMethods: [],
  epochNumber: 6636
}

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Observing behaviour changes on calling the getCurrentEpochNumber function every second.

Screen.Recording.2024-02-28.at.08.43.56.mov

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[glitch003]

this looks good! can you cache the epoch number? like i know we have the event listener that listens to the staking contract events, so i think that should set it in the cache when it changes? if there is a cache miss, then you should fallback to the getCurrentEpochNumber function.

maybe like, set it inside litNodeClient.connect() with getCurrentEpochNumber. and then update it with the event listener when the epoch changes. but remember - we only want to use a new one if it's more than 30s old. so you could put a setTimeout() into the event listener when the epoch changes?

and also, on first page load, in theory you do need to check that it's more than 30s old. you can do this with just the epoch object though. it returns epochLength and endTime in addition to number. you can do (endTime - epochLength) to find the time where the epoch transitioned. if it happened less than 30s ago, you should actually use "epochNumber - 1" and put in a setTimeout to use the new one (aka, epochNumber) 30s after the time when the epoch transitioned.

[glitch003]

beautiful. this is very close - just a note about the max cache age. great job understanding the requirements re: the 30s delay and implementing that.

[glitch003]

i think this should be separate from DELAY_BEFORE_NEXT_EPOCH and have a different max cache age. like the DELAY_BEFORE_NEXT_EPOCH is 30s because we want to give the nodes 30s to see the new epoch. but we can technically cache the current epoch for much longer than that. the epoch time is 60 mins, and the epoch shouldn't change during that time.

and since we have the event listener for when the change happens, i'm not sure we actually even need a max cache age here? what do you think?

i suppose the purpose of the max cache age is, in case we somehow miss an epoch change event? but i don't think that should happen often - even if the event polling fails it should pick up the event on the next poll, and that's like a 5s polling interval. i kinda think we can remove max cache age and handle this corner case in a future PR described below:

we should have error handling in a future PR, to handle the state where the nodes go "hey this epoch is too old!" and the SDK goes "ok let me get and cache the current epoch and retry". but you can't really write that code until we have the error coming from the Node, because you won't know how to handle it. so we can save that for a future PR.

[Ansonhkg]

hmm if we remove the check cacheAge <= MAX_CACHE_AGE here and leaving only this.epochCache.number !== null, we will have a stale state relying on the epoch that we initially set.

If we remove the checks altogether, I'm not sure if we still need to have the whole caching mechanism at all? as we are only setting them and not using them.

I think what we can do is, try to getCurrentEpochNumber() from the staking contract, if it fails, we will use the cache value instead.

☝️should I do this?

[glitch003]

but the event listener will fire and set this.epochCache.number when the epoch changes? so it won't be stale, it will always be up to date?

[Ansonhkg]

Yes, it won't for the first time because this.epochCache.number is null, then it will get the epoch number from the contract and set the cache, then the second time the event listener will just return this.epochCache.number because it's not null anymore.

[Ansonhkg]

Let me know if this change works? 53bacb9 @glitch003

[glitch003]

let's merge this, but i think we should do a follow up next that adds one more feature.

when we initially pull the epoch number, we should also pull the timestamp of when that epoch transitioned. and then, if that's less than 30s ago, we minus 1 (unless the epoch is 1), and then setTimeout so that when it has been 30s from the epoch transition, we start using the new one.