[RC] 2.2.0

[dev-jodee]

Important

This pull request adds a new getVersion method, deprecates the transferTransaction endpoint, and updates tests and configurations accordingly.

• Features:
  • Add getVersion method to retrieve server version in client.ts and rpc.rs.
  • Deprecate transferTransaction endpoint, update related tests in integration.test.ts and transfers.rs.
• Testing:
  • Update unit and integration tests to cover new getVersion method in unit.test.ts and integration.test.ts.
  • Modify tests to handle deprecated transferTransaction endpoint in transfers.rs and token_2022_test.rs.
  • Add new test configurations in auth-test.toml, fee-payer-policy-test.toml, and other .toml files.
• Configuration:
  • Update .toml files to reflect new features and deprecations, including kora-test.toml and paymaster-address-test.toml.

^{This description was created by for 818d8bd. You can customize this summary. It will automatically update as commits are pushed.}

📊 Unit Test Coverage

Unit Test Coverage: 81.9%

View Detailed Coverage Report

[github-actions]

📊 TypeScript Coverage Report

Coverage: 80.3%

View detailed report

Coverage artifacts have been uploaded to this workflow run.
View Artifacts

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 818d8bd in 6 minutes and 21 seconds. Click for details.

• Reviewed 7775 lines of code in 96 files
• Skipped 13 files when reviewing.
• Skipped posting 28 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. examples/x402/demo/.env.example:1

• Draft comment:
  Consider adding inline comments explaining required ENV keys (e.g. KORA_SIGNER_ADDRESS, KORA_SIGNER_PRIVATE_KEY) to help new operators.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

2. examples/x402/demo/api/src/api.ts:12

• Draft comment:
  Good use of typed Resource template literal. Ensure that env values match expected format.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

3. examples/x402/demo/api/src/api.ts:27

• Draft comment:
  The check for KORA_SIGNER_ADDRESS is explicit; consider logging which variable is missing to aid debugging.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50% None

4. examples/x402/demo/facilitator/src/facilitator.ts:48

• Draft comment:
  Endpoints for verify and settle are straightforward; consider adding more detailed logging for production diagnostics.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50% None

5. sdks/ts/src/client.ts:250

• Draft comment:
  Marking transferTransaction as deprecated is good. Ensure that users are encouraged to use getPaymentInstruction.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

6. sdks/ts/src/client.ts:315

• Draft comment:
  The getPaymentInstruction method correctly derives ATAs. Verify that getTransferInstruction produces the expected structure.
• Reason this comment was not posted:
  Confidence changes required: 10% <= threshold 50% None

7. sdks/ts/test/integration.test.ts:140

• Draft comment:
  Integration tests are thorough. Consider also testing boundary conditions for fee estimation and payment instruction math.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

8. sdks/ts/test/unit.test.ts:20

• Draft comment:
  Unit tests correctly mock global fetch; ensure that error cases (e.g., malformed JSON) are also tested.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50% None

9. tests/rpc/transfers.rs:6

• Draft comment:
  RPC transfer tests assume unsigned transactions. Validate that simulation of the transaction returns no error.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

10. tests/src/common/fixtures/auth-test.toml:5

• Draft comment:
  Auth configuration includes API key and HMAC; ensure associated tests cover header inclusion.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50% None

11. tests/src/common/fixtures/fee-payer-policy-test.toml:55

• Draft comment:
  This config file sets all fee payer permissions to false; verify downstream tests correctly handle restrictive policies.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

12. tests/src/common/fixtures/kora-test.toml:13

• Draft comment:
  Configuration for integration tests is detailed. Verify that 'estimate_transaction_fee' flag and get_version flag are set as intended.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

13. tests/src/common/fixtures/paymaster-address-test.toml:2

• Draft comment:
  Paymaster address is set to a specific value; ensure tests differentiate between fee payer and payment address.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

14. tests/tokens/token_2022_test.rs:12

• Draft comment:
  Token 2022 transfer tests are comprehensive. Confirm that the unsigned transaction decoding uses TransactionUtil correctly.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

15. tests/src/common/fixtures/kora-free-test.toml:1

• Draft comment:
  This file is for free pricing tests. Ensure 'price' is set to 'free' to bypass fee validations in tests.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

16. tests/src/common/fixtures/kora-test.toml:1

• Draft comment:
  Configurations for kora tests include custom settings. Verify that enabled_methods include get_version.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

17. tests/src/common/fixtures/paymaster-address-test.toml:1

• Draft comment:
  Paymaster address test config is set with both signer and payment address. Ensure that tests properly compare these.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

18. sdks/ts/package.json:3

• Draft comment:
  Version set to beta; ensure documentation and changelog indicate changes for beta release.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

19. sdks/ts/src/client.ts:64

• Draft comment:
  Using crypto.createHmac for HMAC signature; consider parameterizing hash algorithm (currently hardcoded as 'sha256').
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

20. sdks/ts/src/types/index.ts:141

• Draft comment:
  Documentation for GetVersionResponse is clear; ensure consistent formatting with other response types.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

21. sdks/ts/test/integration.test.ts:227

• Draft comment:
  Test for getPaymentInstruction is detailed; consider verifying payment instruction data bytes in addition to account addresses.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

22. sdks/ts/test/unit.test.ts:85

• Draft comment:
  Unit tests adequately cover basic RPC methods. Consider adding tests for HMAC header generation when hmacSecret is provided.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

23. tests/src/common/fixtures/auth-test.toml:1

• Draft comment:
  Auth test config looks good. Consider adding comments to indicate which environment variable names must be set by users.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50% None

24. CHANGELOG.md:19

• Draft comment:
  The changelog entry "- sign if create ata ix found" on this line seems potentially unclear. It might be a typographical error (e.g. missing a word or using an incorrect abbreviation). Could you please double-check and clarify the intended wording?
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to double-check and clarify the wording of a changelog entry, which violates the rule against asking the author to confirm or explain their intention. The comment does not provide a specific code suggestion or ask for a test to be written, so it should be removed.

25. CLAUDE.md:392

• Draft comment:
  Typographical: The ComputeBudget address now appears to have one less '1' than before. Please confirm if this is intentional or a typo.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

26. README.md:67

• Draft comment:
  Typographical suggestion: The phrase "Get Kora running locally minutes" in this line seems awkward. Consider inserting a preposition (e.g., "in minutes") for clarity.
• Reason this comment was not posted:
  Comment was on unchanged code.

27. examples/deploy/kora.toml:97

• Draft comment:
  There is an extra '#' in the comment on the margin configuration (line 97). Consider removing the extra '#' to clean up the comment.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is pointing out a minor formatting issue - there's an extra # in the comment on line 97. While this is technically correct, I need to consider if this meets the bar for a useful comment. The rules state "Do NOT make comments that are obvious or unimportant." A double # in a comment is a very minor cosmetic issue that doesn't affect functionality at all. It's purely a formatting/style issue. The rules also say to only comment if there's "clearly a code change required" and not to make "obvious or unimportant" comments. This seems to fall into the "unimportant" category - it's just a minor typo in a comment that has no functional impact. While the comment is technically correct about the extra #, this is an extremely minor cosmetic issue. The rules explicitly state not to make obvious or unimportant comments, and a double # in a comment seems to fall into that category. It's not affecting functionality or clarity in any meaningful way. You're right - this is a trivial formatting issue that doesn't warrant a review comment. While it's technically correct, it's the kind of minor typo that doesn't meet the bar for "clearly a code change required." It's unimportant and obvious. This comment should be deleted. While technically correct about the extra #, it's an unimportant cosmetic issue that doesn't meet the bar for review comments. The rules explicitly state not to make obvious or unimportant comments.

28. examples/x402/demo/api/src/api.ts:69

• Draft comment:
  Typo/Formatting: The file does not end with a newline. Please add a newline at the end of the file to adhere to standard formatting practices.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 15% vs. threshold = 50% This comment is about a very minor formatting issue - missing a newline at the end of the file. According to the rules, I should not comment on things that are "obvious or unimportant" and should only comment if "there is clearly a code change required." While some linters enforce this, it's typically a very minor style issue. More importantly, this type of formatting issue would almost certainly be caught by automated linting tools (ESLint, Prettier, etc.) during the build process, and the rules explicitly state "Do NOT comment on anything that would be obviously caught by the build." Missing newlines at end of file are commonly caught by linters and formatters. However, not all projects have linters configured to catch this, and it is a legitimate style convention in many codebases. Some teams consider this important for POSIX compliance and clean git diffs. The comment does suggest a clear, actionable change. While it's true that not all projects have this configured, the rule explicitly states to not comment on things that would be "obviously caught by the build." Most modern TypeScript/JavaScript projects use ESLint or Prettier which catch this by default. Additionally, this falls under "obvious or unimportant" - it's a trivial formatting issue that doesn't affect functionality. The rules emphasize only commenting when there's a clear code change required, not formatting nitpicks. This comment should be deleted. It's about a minor formatting issue (missing newline at EOF) that would typically be caught by automated linting tools, and it falls under the category of "obvious or unimportant" comments that the rules explicitly say to avoid.

Workflow ID: wflow_zH4z4w3sl5sdqBpr

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}