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

Extend fuel-client queries to return the "extensions" map from responses #2605

Open
acerone85 opened this issue Jan 21, 2025 · 0 comments
Open
Assignees

Comments

@acerone85
Copy link
Contributor

Following #2473, the FuelClient can setup the current_fuel_block_height extensions field in requests as follows:

let mut client: FuelClient = FuelClient::from(srv.bound_address);
client.with_required_fuel_block_height(100);

However, currently there is no way to retrieve the response headers from the client. There are two main issues that prevent it:

  • the Client::query method returns an Err value if queries fail, but we want to return the extensions map also in case of errors.
  • changing the signature of Client::query would break several tests

Proposed solutions:

  1. Add a field to store the response extensions to the Client
    Pros:
  • does not require changing the signature of Client::query.
  • Can retrieve the extensions map in case of errors
    Cons:
  • Would not work very well with parallel tests
  1. Create a new Client::extended_query that returns the extensions map together with the graphql response
    Pros:
  • Each requests will receive its own extensions map. Works well for parallel tests

Cons:

  • Would still not be able to retrieve the map in case of errors
  • Each of the function that calls query (there are quite a lot) will need a counterpart that calls extended_query (we could have a macro for that)
  1. Create a new Client::extended_query function that takes in input a mutable reference to the extensions map to be filled.

Pros:

  • Each request will have its own extension map. Works well for parallel tests
  • Will still be able to set the extensions map in case of error

Cons:

  • Setting a mutable map is kind of a side effect
  • Will still need to create an "extended" counterpart to each function that calls "Client::query".
@acerone85 acerone85 self-assigned this Jan 21, 2025
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

No branches or pull requests

1 participant