[Access] Add an API to query system transactions by ID
Problem Definition
Right now there is no way to query system transactions by ID only, we have to provide the block ID as well, which is not great DX.
With the scheduled transaction feature, the users will want to query for the transaction ID that executed their scheduled transaction. Requiring to also pass block ID makes this API very strange for usage.
Proposed Solution
We could add an API that allows querying system transactions without providing a block ID, or, maybe better, we should add querying system transactions by ID to the current getTransaction API.
Isn't this a limitation because the system transactions are non-deterministic (e.g. no reference block/nonce)? So you need to know the block to query them?
I think for scheduled tx, they will always get a unique ID because they include the callback uuid as an argument. I assume that the uuid would only ever be included in a single tx, but not sure if we have any explicit checks for that.
Is this something that's problematic for testnet, or can we just fix it by adding scheduled tx specific endpoints that support querying by callback id?
I think for scheduled tx, they will always get a unique ID because they include the callback uuid as an argument. I assume that the uuid would only ever be included in a single tx, but not sure if we have any explicit checks for that.
Is this something that's problematic for testnet, or can we just fix it by adding a schedule tx specific endpoints that support querying by callback id?
My ideal DevEx is querying by callback ID since this is an existing canonnical identifier that devs are already familiar with & can easily obtain. The schedule TX endpoints performing some sort of indexing would definitely be my preference since I'm not clear yet on how developers can otherwise locate the block where the callback ultimately executes.
Querying by scheduled transaction (callback) ID is definitely a valuable addition to our APIs. My concern is that users who observe on-chain executions will see events tied to a transaction ID and naturally expect to query that transaction directly. Right now, there’s a disconnect because those transactions cannot be retrieved using the getTransaction endpoint.
It previously made sense for system transactions to be unqueryable given the nature of their IDs and the limited user interest. However, scheduled system transactions now carry real value, and it feels unintuitive to require users to query them in a different, less natural way.
If we supported getTransaction by ID for scheduled transactions, we could maintain a very light index of executed callbacks that includes both the "callback" ID and block height. That would enable querying by either the scheduled transaction ID or the corresponding on-chain transaction ID. In fact, such an index seems necessary regardless.
I think for scheduled tx, they will always get a unique ID because they include the callback uuid as an argument. I assume that the uuid would only ever be included in a single tx, but not sure if we have any explicit checks for that.
Yes it would, and each executed callback transaction will have unique ID.
Is this something that's problematic for testnet, or can we just fix it by adding scheduled tx specific endpoints that support querying by callback id?
We don't need it for testnet but I would argue we need it for mainnet. It just makes DX very hard right now.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
this is complete