Add GraphQL extension to provide current STF and CP versions

[rafal-ch]

Linked Issues/PRs

Closes #2596

Description

This PR adds new GraphQL extensions to provide:

• current STF version
• current consensus parameters version

Example response:

{
  "data": {
    "nodeInfo": {
      "nodeVersion": "0.41.6"
    }
  },
  "extensions": {
    "current_consensus_parameters_version": 0,
    "current_fuel_block_height": 0,
    "current_stf_version": 21
  }
}

Additional housekeeping changes:

• all graphql extensions have been moved into a subdirectory

TODO

• Add tests to check that correct versions are returned when STF or CP are bumped
• Rework how we retrieve the current STF version

Checklist

• Breaking changes are clearly marked as such in the PR description and changelog
• New behavior is reflected in tests

Before requesting review

• I have reviewed the code myself
• I have created follow-up issues caused by this PR and linked them here

After merging, notify other teams

• Rust SDK

[rafal-ch]

We might prefer reading the current STF version directly from on chain DB table StateTransitionBytecodeVersions similarly to how it's done in BlockProducerDatabase::latest_state_transition_bytecode_version(), but I couldn't figure out how to access this in GraphQL.

[xgreenx]

We need to have a place where we cache this kind of information. Maybe, we could extend consensus parameters provider to also provide this kind of information, because fetch it from the database it a lot of waste work.

[acerone85]

If we do that, it might be useful to also add the block height to the information retrieved, as in this case all the extension metadata will come from the same place.

Btw, If I am not mistaken all the information we want to fetch comes from the block header right now, so maybe a HeaderProvider trait with a function that returns the whole block header, and then stf_version and consensus_parameters_version and block_height can be provided methods?

[rafal-ch]

I think I'll prefer to extend (and rename) the "Consensus Parameters Provider". However, I find caching the entire block header not optimal and my preference would be to cache exactly what we need. So, in addition to the current data, it'll store:

• current STF version
• current block height

wdyt?

[rafal-ch]

Currently, the STF version is cached in the "Consensus Parameters Provider", so we do not read from the DB every time, but handling of the current block height remains unchanged from the original implementation.

[rafal-ch]

We're currently attaching some substantial number of bytes to every response. Even if user requests just the node version, he will get a bunch of additional data, which, AFAIK, cannot be opted-out from.

{
  "data": {
    "nodeInfo": {
      "nodeVersion": "0.41.6"
    }
  },
  "extensions": {
    "current_consensus_parameters_version": 0,
    "current_fuel_block_height": 0,
    "current_stf_version": 21
  }
}

Not sure if this should be a concern, but I thought it's worth pointing out.

[rymnc]

We're currently attaching some substantial number of bytes to every response. Even if user requests just the node version, he will get a bunch of additional data, which, AFAIK, cannot be opted-out from.

{
  "data": {
    "nodeInfo": {
      "nodeVersion": "0.41.6"
    }
  },
  "extensions": {
    "current_consensus_parameters_version": 0,
    "current_fuel_block_height": 0,
    "current_stf_version": 21
  }
}

Not sure if this should be a concern, but I thought it's worth pointing out.

we miss the whole point of graphql here, if we provide data no one asked for :(

[rafal-ch]

we miss the whole point of graphql here, if we provide data no one asked for :(

Exactly, that's why I was thinking that we should just provide this data via some info endpoint, but IIUC, the idea here is to provide this data proactively instead of requiring users to poll regularly.

Maybe there's a way to opt out from extensions which I'm just missing.

[xgreenx]

I think spawning a separate extension for the field it is too overkill=D It decreases performance without any reason

[xgreenx]

I think we can have one extension fully dedicated to return information to the end user. Like STFV, CPV, current block height(we can remove setting of the current height from the RequiredFuelBlockHeightExtension).

In this case we will have one extension that we can use to add any metadata

[rafal-ch]

The following changes have been made:

• Both STF and CP extensions have been merged into "chain state info" extension
• The "chain state info" extension is now also providing data about the current block height

[xgreenx]

We need to have a place where we cache this kind of information. Maybe, we could extend consensus parameters provider to also provide this kind of information, because fetch it from the database it a lot of waste work.

[xgreenx]

fuel-core-client should fetch this information in the same way how it is done for the required block height. We have ExtensionsResponse where you can add several new fields.

Implementation details: In the case of the CPV and STFV we don't need any policy, we just can fetch the latest one and provide a getter

[rafal-ch]

Updated in ef9c445

[xgreenx]

we miss the whole point of graphql here, if we provide data no one asked for :(

The extensions field is part of the GraphQL specification, and we can put there any data what we want. The user controls only the data field.

[xgreenx]

If you are able to use &self, then you can remove inner_required_height(move logic inside update_chain_state_info) and update everything in one function=)

[xgreenx]

You have a deadlock here. self.shared_state.cache_consensus_parameters is doing write lock inside and update_cached_value is doing upgradable lock

[acerone85]

nit: the name consensus_parameters_provider should be changed to something that indicates that we also return the stf version, but probably fine to rename it later.

[rafal-ch]

Yes, I agree. Here's the follow-up issue: #2754

[rafal-ch]

Follow-up PR: #2761

[acerone85]

not for this PR, but out of curiosity: why is this not a provided method?

[rafal-ch]

Not sure, I just did the rename, didn't investigate further.

[acerone85]

this seems to be equivalent to #[derive(Clone)], or am I missing something?

code generated by #[derive(Clone)]:

impl<T: core::clone::Clone> core::clone::Clone for SharedRwLock<T> {
    fn clone(&self) -> Self {
        match self {
            SharedRwLock(f0) => SharedRwLock(f0.clone()),
        }
    }
}

[rafal-ch]

I noticed that custom clone is required for the SharedMutex above, which I used as a base for the SharedRwLock and I decided to just follow the pattern. In this case, it seems that the derived Clone would do the job, indeed.

[acerone85]

for consistency:

Suggested change

	let genesis_version = 0;
	let latest_stf_version = 0;
	let genesis_consensus_parameters_version = 0;
	let genesis_stf_version = 0;

[rafal-ch]

I'll rename this in a follow-up PR in order no to block this one any longer.

[rafal-ch]

Follow-up PR: #2761

[acerone85]

Thanks :)
All my comments are minor and definitely not show stoppers.