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

refactor: rename addMissingVariables to estimateTxDependencies, and add docs for tx dep estimation #924

Closed
wants to merge 99 commits into from

Conversation

Dhaiwat10
Copy link
Member

@Dhaiwat10 Dhaiwat10 commented Apr 24, 2023

Summary

As discussed here, this PR renames the addMissingVariables helper to estimateTxDependencies for better consistency with the Rust SDK, and adds a docs page for transaction dependency estimation.

I have based this PR off of @Torres-ssf's docs snippet branch since it contains the updated guides around contracts. This PR should automatically change base to master once his PR is merged.

Closes #701

@Dhaiwat10 Dhaiwat10 changed the base branch from master to torres/docs/add-dedicated-package-code-snippets-contracts April 24, 2023 10:18
@Dhaiwat10 Dhaiwat10 changed the title refactor/docs: rename addMissingVariables to estimateTxDependencies, and add docs for tx dep estimation refactor: rename addMissingVariables to estimateTxDependencies, and add docs for tx dep estimation Apr 24, 2023
Comment on lines +5 to +6
However, the SDK always automatically estimates these dependencies and double-checks if everything is in order whenever you invoke a contract function or attempt to send a transaction.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@digorithm I believe that this behaviour here in the TS SDK is slightly different from the Rust SDK. The Rust SDK doesn't seem to automatically call estimate_tx_dependencies on each function invocation, while the TS SDK does that every single time automatically.

I feel like this would make the estimateTxDependencies function here in the TS SDK more of an internal helper since SDK users will never have to call it manually.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I'd suggest that, in the near future, we should move to manually calling estimateTxDependencies; the additional dry-run calls happening without the user's consent could be an undesired behavior. Or it could be an optional value we set at the call time. We can discuss that later.

@github-actions
Copy link
Contributor

github-actions bot commented Apr 24, 2023

Coverage report

❌ An unexpected error occurred. For more details, check console

Error: The process '/home/runner/setup-pnpm/node_modules/.bin/pnpm' failed with exit code 1
St.
Category Percentage Covered / Total
🟢 Statements
95.09% (+0.01% 🔼)
4702/4945
🟢 Branches
83.97% (-0.04% 🔻)
833/992
🟢 Functions
92.22% (-0.15% 🔻)
901/977
🟢 Lines
95.11% (+0.01% 🔼)
4495/4726

⚠️ Details were not displayed: the report size has exceeded the limit.

Test suite run failed

Failed tests: 1/822. Failed suites: 1/126.
  ● ExampleContract › should return the input

    Transaction id was already used: 0xeab9f726ba65507def084bc3bdd9107c32ea6793f602c3411975f175eee5b5f8: {"response":{"data":null,"errors":[{"message":"Transaction id was already used: 0xeab9f726ba65507def084bc3bdd9107c32ea6793f602c3411975f175eee5b5f8","locations":[{"line":2,"column":3}],"path":["dryRun"]}],"status":200,"headers":{}},"request":{"query":"mutation dryRun($encodedTransaction: HexString!, $utxoValidation: Boolean) {\n  dryRun(tx: $encodedTransaction, utxoValidation: $utxoValidation) {\n    ...receiptFragment\n  }\n}\n\nfragment receiptFragment on Receipt {\n  data\n  rawPayload\n}","variables":{"encodedTransaction":"0x000000000000000000000000000000000000000005f5e1000000000000000000000000000000000400000000000000000000000000000001000000000000000200000000000000010000000000000000000000000000000000000000000000000000000000000000240000000000000000000000000000006b00bb793fec81293cbe8d9d6f180e0ef9a5a87e5e2d47a68394cb7e82ebeaeb000000000000000009c0b2d1a486c439a87bcba6b46a7a1a23f3897cc83a94521a96da5c23bc58dbffffffffbaf3c2010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000309c0b2d1a486c439a87bcba6b46a7a1a23f3897cc83a94521a96da5c23bc58db0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003371ceecdb6f9b8c308ef075845defc4eec5c2056d89aec6d26ad00f47e6564400000000000003e800000000000000000000000000000000000000000000000000000000000000000000000000000040eddac5913738e59f33196df00d3138d480ae28cf740d4e31754e348fb1c673b5ba3cc75ac6eda99f7ba9c1df9e495c034ec91541f4bc6ef869519cc8201dc41d","utxoValidation":false}}}

      at node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-request/src/index.ts:497:11
      at step (node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-request/dist/index.js:63:23)
      at Object.next (node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-request/dist/index.js:44:53)
      at fulfilled (node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-request/dist/index.js:35:58)

Report generated by 🧪jest coverage report action from 67653fe

*
* If there are missing output contract IDs, those are fetched and added to the transaction.
*
* TODO: Add support for missing output messages
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will file a follow-up issue for this.

Copy link
Contributor

@camsjams camsjams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

Base automatically changed from torres/docs/add-dedicated-package-code-snippets-contracts to master April 25, 2023 11:01
Copy link
Contributor

@Torres-ssf Torres-ssf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice job @Dhaiwat10 👍.

But I have one question though

Comment on lines +344 to +346
*
* If there are missing output contract IDs, those are fetched and added to the transaction.
*
Copy link
Contributor

@Torres-ssf Torres-ssf Apr 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this functionality working? When I was rewriting the Inter-contract Calls doc page I was always running into an error before explicitly calling the addContracts function in the contract function chain call.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Torres-ssf there seems to be code in place that would take care of that functionality, but we don't have any tests in place for this.

missingOutputContractIds.forEach(({ contractId }) =>
transactionRequest.addContract(Address.fromString(contractId))
);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Dhaiwat10 I've just tried to validate that and it seems this is not working or at least for not all cases.

It seems this functionality relies on the following logic that is defined here.

receipt.type === ReceiptType.Panic &&
receipt.contractId !== '0x0000000000000000000000000000000000000000000000000000000000000000';

It seems the getReceiptsWithMissingData function loops through all receipts returned from a dryRun call and tries to verify if the receipt type and contractId properties indicate that a contract ID is missing in order to a successful script call.

However, in my tests, when I try to execute a contract call that does an inter-contract call, the receipt does not come with a contractId different than the one specified in the condition, thus, not being a valid case for missing contract ID.

{
  type: 3,
  id: '0x48ca0552db61b135a3731928ce77910c3d3630a554ef313949d6af14930177ba',
  reason: <BN: 0x172d4d2450000000>,
  pc: <BN: 0x481c>,
  is: <BN: 0x4338>,
  contractId: '0x0000000000000000000000000000000000000000000000000000000000000000'
},

I couldn't find out the source of the problem, maybe it could be something in the dry-run call?

Do you have any insight on that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Torres-ssf thanks for looking into this with so much detail. Unfortunately, I don't have a lot of insight on the dry-run implementation, but this is def something we need to fix. I can file a follow-up issue for this. Does that sound good?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Dhaiwat10 Yes that sounds great

@arboleya
Copy link
Member

Just a side note — there are dozens of unrelated commits here. I'd guess this PR wasn't based on the master branch.

@Dhaiwat10
Copy link
Member Author

@arboleya good heavens. I based this PR off of the branch for #895 since I wanted to use some of the work from there. This has blown up 😆

@Dhaiwat10
Copy link
Member Author

Closing this in favor of #954. Tried rebasing this PR against master but there are way too many merge conflicts. Creating a new PR seems to be the wiser choice.

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

Successfully merging this pull request may close these issues.

Implement transaction dependencies estimation
6 participants