Rosetta-cli check construction + dynamic parameter


When sending a transaction, there is an online parameter that needs to be fetched. To do so, we provide such value in /construction/metadata. We are wondering how this parameter will / can be used by rosetta-cli check command. Just to be more precise:

  • When sendind a transaction ttl needs to be provided which states how much time are you willing to wait for the tx to be included. Otherwise is expired.
  • ttl can be calculated by latestBlock.slot + delta. Slot is returned by the server but delta is something the client needs to define.

How can we make rosetta-cli check:construction work on such context?


I’d recommend allowing this TTL value to be specified in /construction/preprocess instead of in /construction/metadata. I wrote about this a little in a previous reply:

We haven’t yet established a pattern for specifying how network-specific metadata should be populated during automated construction. I’d recommend chiming in here:

We could very easily allow for fetching the last processed block while processing a test and for populating /construction/preprocess metadata.

Hi @patrick.ogrady, thanks for your answer.

So, the ttl is something the user needs to specify, it’s not something the API needs or can define. Also, ttl value can be calculated using the latest block (there is already an API endpoint for this) plus a user defined value (that even might change in different calls). What I understand from your answer is:

  1. /construction/metadata whatever comes from the endpoint is sent when building a transaction and is not processed
  2. /construction/preprocess can deal with online data but in this case it’s not needed (see next item)
  3. We could very easily allow for fetching the last processed block while processing so there is no need to return the latestSlotNumber in /construction/preprocess as that data is already there … I don’t see why do we need to return the same data tht’s already there, am I right?

Yes, this is correct. We assume this response contains “network-specific” information that we (by principle in Rosetta) do not think should be modified by the caller.

I wrote a little about this on the website a little but did not emphasize it enough (another team had a similar question about modifying this response).

Payloads is called with an array of operations and the response from `/construction/metadata`.

I was thinking that the caller could provide a TTL (minus the latestSlotNumber) in ConstructionPreprocessRequest.Metadata that could be used by your implementation to determine what the “network-specific” TTL is (a call to get the latestSlotNumber would be made in /construction/metadata).

For example, the caller would provide a TTL of 300 in ConstructionPreprocessRequest.Metadata and this would be represented as latestSlotNumber + 300 in the Metadata passed to /construction/payloads.

Does that make sense?

Hey @patrick.ogrady … yes.

I’m not sure if I’m big fan of placing that kind of logic in the endpoint (speaking in general terms about the API) when It could be easily calculated in the client although I see that if that logic needs to change clients can either not invoke it or just get updates on the logic “for free”

It is very much a design opinion question. Regardless of the approach, we will need to add the ability to set ConstructionPreprocessRequest.Metadata in the automated testing. I added this to the issue tracking changes.

We believe that /construction/preprocess metadata should never require the population of live data (as this would require some network-specific data fetching strategy outside of the Construction API and require more network-specific services to live outside of a Rosetta implementation). I believe any live data should be fetched using /construction/metadata as directed by the Options returned by the call to /construction/preprocess (which is passed to the /construction/metadata request).

1 Like

I wrote up a PR to clarify these details.

1 Like