Skip to content

Conversation

tabaktoni
Copy link
Member

@tabaktoni tabaktoni commented Aug 6, 2025

Motivation and Resolution

Fix: #1455
Fix: #1014

  • Extend parser so that the user can define parsing classes for types and response type (extend parser to configurable response/request parsing)
  • Integrate New ByteArray to parser
  • Docs
  • Integration tests (ByteArray)
  • Events emitted tests (ByteArray)
  • Unit tests
  • ByteArray integration tests without parser
  • Extend Contract Class to set up a custom parser map config
  • Other CairoType integers
  • reduce waitForTransaction waiting time when TTL and return knows fail reason

RPC version (if applicable)

Usage related changes

TODO

Development related changes

TODO

Checklist:

  • Performed a self-review of the code
  • Rebased to the last commit of the target branch (or merged it into my branch)
  • Linked the issues which this PR resolves
  • Documented the changes in code (API docs will be generated automatically)
  • Updated the tests
  • All tests are passing

Copy link
Collaborator

@PhilippeR26 PhilippeR26 left a comment

Choose a reason for hiding this comment

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

Just few comments.

@tabaktoni tabaktoni marked this pull request as ready for review August 13, 2025 12:22
* feat: reduce TX wait time, and provide known failed reasons based on TX flow

* test: eventless write bytearray xtest

* feat: uint static factory methods

* refactor: cleanup

* feat: missing primitive integers implemented as cairo types

* chore: cleanup
Copy link
Collaborator

@penovicp penovicp left a comment

Choose a reason for hiding this comment

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

The comments I would emphasize relate to the usage of Buffer, the rest are mostly concerned with tidying up.

expect(isShortString(shortStr)).toBe(true);
});

test('should return true for short strings', () => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should this test be kept? Would it make sense to add an isASCII check inside isShortString and note that constraint in its description?

Copy link
Member Author

Choose a reason for hiding this comment

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

isShortString is bugged. I left a note below for todo, it should be fixed or removed. But I tried to minimize the scope of this PR, as it already gets huge.

* @param hex string to check
* @returns true if hex string
*/
function isHexString(hex: string): boolean {
Copy link
Collaborator

Choose a reason for hiding this comment

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

A hex check function is present in both encode and num.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes circular issue so this was the simplest solution.

case isTypeBytes31(type):
return encodeShortString(val.toString());
return parser.getRequestParser(type)(val);
case CairoUint8.isAbiType(type):
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could have all the uint/int cases fall through to a shared return. Same thing in the response parser.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, I also taught about this, but
It would break the pattern of enclosed class, so I would need to have a generic CairoInt class that only has this check, or a generic Inc Class that spawns all Int types. In any case, I leave it for some future PR where it would need to be taught true.

Copy link
Member Author

Choose a reason for hiding this comment

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

Or some other solution...


/**
* !! Main design decision:
* Class can't extend GetTransactionReceiptResponse because it is union type
Copy link
Collaborator

Choose a reason for hiding this comment

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

Since the union members from GetTransactionReceiptResponse overlap in their properties, it might be worth trying implements SomeType where SomeType is:

{ [k in keyof GetTransactionReceiptResponse]: GetTransactionReceiptResponse[k] }
//or
Pick<GetTransactionReceiptResponse, keyof GetTransactionReceiptResponse>

Copy link
Member Author

Choose a reason for hiding this comment

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

I tried and failed miserably, I see a solution in not having an error case, but for the scope of PR, i leave this to some other PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

Extending this way return type would have only common props and not base props spread from the Api, and that was the point of this refactor, to have those props visible to TS.

@tabaktoni tabaktoni merged commit 430fb70 into develop Aug 15, 2025
3 checks passed
github-actions bot pushed a commit that referenced this pull request Aug 15, 2025
# [8.2.0](v8.1.2...v8.2.0) (2025-08-15)

### Features

* a CairoByteArray, CairoTypes, updates ([#1469](#1469)) ([430fb70](430fb70)), closes [#1472](#1472)
Copy link
Contributor

🎉 This PR is included in version 8.2.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@penovicp penovicp deleted the fix/1455 branch August 27, 2025 12:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Incorrect ByteArray encoding/decoding Add test and support for negative Signed integers smaller than 252 bits

3 participants