feat: get transaction status #499
Conversation
|
To view this pull requests documentation preview, visit the following URL: docs.page/focustree/starknet.dart~499 Documentation is deployed and generated using docs.page. |
WalkthroughThis pull request introduces a new Changes
Suggested labels
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (2)
🔇 Additional comments (4)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
packages/starknet_provider/lib/src/model/index.dart (1)
37-37: Export order should follow alphabetical patternThe new export for 'get_transaction_status.dart' has been added at the end of the file, but the existing exports appear to be in alphabetical order. For consistency, consider moving this line between 'get_transaction_receipt.dart' (line 24) and 'invoke_transaction.dart' (line 25).
24 export 'get_transaction_receipt.dart'; +export 'get_transaction_status.dart'; 25 export 'invoke_transaction.dart';packages/starknet_provider/lib/src/model/get_transaction_status.dart (1)
1-15: Implementation looks good but could benefit from additional documentationThe TransactionStatus model is correctly implemented with the required and optional fields. The design follows the Freezed pattern for immutable data models with JSON serialization support.
Consider adding documentation comments to explain:
- The purpose of this class
- The meaning of each status value (RECEIVED, REJECTED, ACCEPTED_ON_L2, ACCEPTED_ON_L1, SUCCEEDED, REVERTED)
- When executionStatus might be null
@freezed +/// Represents the status of a Starknet transaction. +/// +/// Contains information about both the finality status (indicating where in the +/// lifecycle the transaction is) and execution status (if it succeeded or failed). class TransactionStatus with _$TransactionStatus { const factory TransactionStatus({ + /// The finality status of the transaction. + /// Possible values: + /// - RECEIVED: Transaction is received but not yet processed + /// - REJECTED: Transaction was rejected + /// - ACCEPTED_ON_L2: Transaction is accepted on L2 + /// - ACCEPTED_ON_L1: Transaction is accepted on L1 required String finalityStatus, + /// The execution status of the transaction. + /// Possible values: + /// - SUCCEEDED: Transaction executed successfully + /// - REVERTED: Transaction execution failed + /// May be null if the transaction hasn't been executed yet. String? executionStatus, }) = _TransactionStatus;packages/starknet_provider/test/get_transaction_status_test.dart (2)
13-34: Consider more robust test setupThe test setup establishes a connection to a local devnet and verifies it responds. While this works, it might be worth handling potential connection issues more gracefully.
Consider adding timeout handling and a more descriptive failure message:
setUp(() async { provider = JsonRpcReadProvider(nodeUri: Uri.parse('http://127.0.0.1:5050')); // First verify the devnet is responding - final chainIdResponse = await http.post( - Uri.parse('http://127.0.0.1:5050'), - headers: {'Content-Type': 'application/json'}, - body: jsonEncode({ - 'jsonrpc': '2.0', - 'method': 'starknet_chainId', - 'params': [], - 'id': 1, - }), - ); - print('Chain ID response: ${chainIdResponse.body}'); + try { + final chainIdResponse = await http.post( + Uri.parse('http://127.0.0.1:5050'), + headers: {'Content-Type': 'application/json'}, + body: jsonEncode({ + 'jsonrpc': '2.0', + 'method': 'starknet_chainId', + 'params': [], + 'id': 1, + }), + ).timeout(Duration(seconds: 5)); + print('Chain ID response: ${chainIdResponse.body}'); + + final result = jsonDecode(chainIdResponse.body); + expect(result['error'], isNull, + reason: 'Failed to connect to devnet: ${chainIdResponse.body}'); + } catch (e) { + fail('Failed to connect to devnet: $e. Make sure the devnet is running at http://127.0.0.1:5050'); + } // Use a known transaction hash for non-existent transaction test txHash = Felt.fromHexString( '0x03b2911796e0024f9e23d7337997538058eca267d5ddaa582d482cbe1fb64897'); print('Using tx_hash: ${txHash.toHexString()}'); });
1-241: Consider adding test for error handlingThe test suite covers successful scenarios and parsing variations, but could be enhanced with tests for error handling.
Add a test for handling malformed responses, such as:
test('should handle malformed responses', () async { // Test missing required field final missingRequiredField = { 'jsonrpc': '2.0', 'id': 1, 'result': { // No finality_status field 'execution_status': 'SUCCEEDED' } }; // Expecting an exception due to missing required field expect( () => TransactionStatus.fromJson( missingRequiredField['result'] as Map<String, dynamic>), throwsA(isA<TypeError>()), ); // Test invalid field values final invalidFieldValues = { 'jsonrpc': '2.0', 'id': 1, 'result': { 'finality_status': 'INVALID_STATUS', 'execution_status': 'UNKNOWN' } }; // Should parse but values would not match expected enum values final status = TransactionStatus.fromJson( invalidFieldValues['result'] as Map<String, dynamic>); expect(status.finalityStatus, equals('INVALID_STATUS')); expect(status.executionStatus, equals('UNKNOWN')); // Verify that the values don't match expected enums expect( ['RECEIVED', 'REJECTED', 'ACCEPTED_ON_L2', 'ACCEPTED_ON_L1'] .contains(status.finalityStatus), isFalse, ); expect( ['SUCCEEDED', 'REVERTED'].contains(status.executionStatus), isFalse, ); });packages/starknet_provider/lib/src/model/get_transaction_status.freezed.dart (1)
167-186: LGTM: Abstract class declaration matching implementationThe abstract class definition properly declares the interface that the implementation must satisfy, with the same required/optional parameters.
Consider adding an enumeration or constants for the possible values of
finalityStatus(RECEIVED, REJECTED, ACCEPTED_ON_L2, ACCEPTED_ON_L1) andexecutionStatus(SUCCEEDED, REVERTED) in the non-generated file to improve type safety and provide better intellisense support.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
packages/starknet_provider/lib/src/model/get_transaction_status.dart(1 hunks)packages/starknet_provider/lib/src/model/get_transaction_status.freezed.dart(1 hunks)packages/starknet_provider/lib/src/model/get_transaction_status.g.dart(1 hunks)packages/starknet_provider/lib/src/model/index.dart(1 hunks)packages/starknet_provider/test/get_transaction_status_test.dart(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: analyze
- GitHub Check: test-integration
- GitHub Check: lint
🔇 Additional comments (10)
packages/starknet_provider/lib/src/model/get_transaction_status.g.dart (1)
1-22: Generated code looks correctThe JSON serialization code correctly maps between the snake_case JSON fields (
finality_status,execution_status) and the camelCase Dart properties (finalityStatus,executionStatus). This is consistent with standard JSON conventions.packages/starknet_provider/test/get_transaction_status_test.dart (3)
36-55: Test handles error case appropriatelyGood test for handling non-existent transaction hash, verifying both the error code and message.
179-218: Good unit test for successful transaction parsingThis test effectively validates that the TransactionStatus model can correctly parse a JSON response with both finality_status and execution_status fields.
220-239: Good unit test for handling optional fieldsThis test properly verifies that the TransactionStatus model can handle a response with only the required finality_status field, where execution_status is missing.
packages/starknet_provider/lib/src/model/get_transaction_status.freezed.dart (6)
1-5: LGTM: Generated file header with appropriate ignoresThe file correctly starts with standard ignores for generated code, which prevents linting issues and coverage reports.
6-11: LGTM: File part declaration and generator headerThis correctly identifies the file as part of the main
get_transaction_status.dartfile, indicating the model definition is in that file.
36-74: LGTM: CopyWith implementationThe generated copyWith implementation follows the standard Freezed pattern with proper null safety handling.
116-129: LGTM: TransactionStatus implementation with proper serialization annotationsThe implementation correctly:
- Uses JsonSerializable for JSON conversion
- Requires finalityStatus
- Makes executionStatus optional
This matches the expected behavior for transaction status queries in Starknet.
130-164: LGTM: Standard object method overridesThe implementation correctly overrides:
- toString() for debugging
- equals operator for comparing instances
- hashCode for use in collections
- toJson() for serialization
These are all properly implemented following best practices.
21-34:✅ Verification successful
TransactionStatus model structure looks good
The model correctly defines:
finalityStatusas required stringexecutionStatusas optional stringThis aligns with the PR objectives which mentioned these two status types for the Starknet transaction status RPC method.
🌐 Web query:
What are the standard transaction statuses in StarkNet?💡 Result:
Starknet transactions progress through distinct statuses reflecting their lifecycle from submission to finalization. These statuses are categorized into finality statuses (indicating transaction acceptance on the network) and execution statuses (indicating the outcome of transaction processing).
Finality Statuses
RECEIVED:
The transaction is validated by the mempool and awaits processing by the Sequencer. This is analogous to Ethereum’s mempool state[1][4].
ACCEPTED_ON_L2:
The transaction is included in a Starknet block and applied to the L2 state. This indicates L2 finality, though reversibility is theoretically possible if Sequencers collude[1][3][4].
ACCEPTED_ON_L1:
The transaction achieves absolute finality after the block’s STARK proof is verified on Ethereum L1. This aligns with Ethereum’s consensus security[1][3][7].
REJECTED:
The transaction fails initial validation (e.g., invalid signature or insufficient fees) and is excluded from blocks[1][4].Execution Statuses
SUCCEEDED:
The transaction executed successfully and modified the L2 state as intended[1][4][5].
REVERTED:
The transaction passed validation but failed during execution (e.g., a smart contract error). State changes are rolled back, but the transaction is recorded in the block[1][4][5].
NOT_RECEIVED:
The transaction was not acknowledged by the Sequencer, typically due to network issues[4].Key Workflow Examples
- A transaction may transition:
RECEIVED→ACCEPTED_ON_L2→ACCEPTED_ON_L1(if fully finalized).- A failed transaction might follow:
RECEIVED→REVERTED(execution failure) orREJECTED(validation failure).Developers can check these statuses using tools like
starkli transaction_receiptor Starknet-py’sfetch_transaction_receipt[1][8]. The distinction between L2 and L1 finality is critical for applications requiring Ethereum-level security guarantees[3][7].Citations:
- 1: https://book.starknet.io/zh-cn/ch03-01-01-transactions-lifecycle.html
- 2: https://docs.starknet.io/architecture-and-concepts/network-architecture/starknet-architecture-overview/
- 3: https://www.coinex.network/en/blog/8020-what-is-starknet-strk
- 4: https://docs.starknet.io/architecture-and-concepts/network-architecture/transaction-life-cycle/
- 5: https://docs.starknet.io/architecture-and-concepts/network-architecture/starknet-state/
- 6: https://docs.dune.com/data-catalog/starknet/transactions
- 7: https://www.imperator.co/fr/resources/blog/what-is-starknet
- 8: https://starknetpy.readthedocs.io/en/latest/api/account.html
- 9: https://docs.starknet.io/architecture-and-concepts/network-architecture/transactions/
- 10: https://dev.to/bastienfaivre/a-starknet-transactions-batcher-1hpk
TransactionStatus model structure is validated and aligns with Starknet standards.
Both the requiredfinalityStatusand optionalexecutionStatusfields correctly reflect the two distinct status categories used in Starknet (e.g., finality statuses likeRECEIVED,ACCEPTED_ON_L2,ACCEPTED_ON_L1,REJECTEDand execution statuses likeSUCCEEDED,REVERTED,NOT_RECEIVED). This confirms that the implementation meets the PR objectives and mirrors the statuses described in the official documentation.
packages/starknet_provider/test/get_transaction_status_test.dart
Outdated
Show resolved
Hide resolved
jaiminRaiyani
changed the title
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
docs/packages/starknet-provider.mdx (1)
68-69: Cleanup of Redundant Documentation
The removal of the outdated description forstarknet_getBlockWithReceiptsin the "Call read-only method" section helps declutter the documentation. Please verify that any crucial details for users regarding this method are still documented elsewhere if needed. Additionally, note the static analysis hint about loose punctuation; if reintroducing similar content in the future, consider tightening the phrasing.🧰 Tools
🪛 LanguageTool
[uncategorized] ~68-~68: Loose punctuation mark.
Context: ...ethod -starknet_getBlockWithReceipts: Retrieves block information with transa...(UNLIKELY_OPENING_PUNCTUATION)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/packages/starknet-provider.mdx(2 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/packages/starknet-provider.mdx
[uncategorized] ~68-~68: Loose punctuation mark.
Context: ...ethod - starknet_getBlockWithReceipts: Retrieves block information with transa...
(UNLIKELY_OPENING_PUNCTUATION)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: test-integration
- GitHub Check: lint
- GitHub Check: analyze
🔇 Additional comments (2)
docs/packages/starknet-provider.mdx (2)
34-34: New RPC Method Entry Added
The addition of thestarknet_getTransactionStatusrow in the Supported JSON RPC methods table is clear and accurately reflects the new feature. Please ensure that the table’s column alignment and formatting remain consistent with the rest of the table.
70-88: Comprehensive Documentation forstarknet_getTransactionStatus
The new documentation section forstarknet_getTransactionStatusis thorough and well-structured. It provides a concise method description, an example with a code snippet, and details about theTransactionStatusmodel’s properties. Ensure that the field names (finalityStatusandexecutionStatus) are consistent with the implementation.
jaiminRaiyani
changed the title
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
packages/starknet_provider/test/get_transaction_status_test.dart (3)
171-194: Redundant test cases can be consolidated.Tests "should return transaction status with required finality_status field" and "should handle transaction status with only finality_status field" are nearly identical, both checking that the transaction has a finality status. Consider consolidating them or making their purposes more distinct.
Consolidate the duplicate test cases or clarify their distinct purposes:
test('should return transaction status with required finality_status field', () async { expect(successfulTxHash, isNotNull, reason: 'Previous test must succeed to get a valid transaction hash'); final response = await http.post( devnetUri, headers: {'Content-Type': 'application/json'}, body: jsonEncode({ 'jsonrpc': '2.0', 'method': 'starknet_getTransactionStatus', 'params': [successfulTxHash], 'id': 1, }), ); final result = jsonDecode(response.body); expect(result['error'], isNull, reason: 'Failed to get transaction status'); final status = TransactionStatus.fromJson(result['result']); expect(status.finalityStatus, isNotNull, reason: 'Transaction status should have a finality status'); + // Also verify fields are of expected types + expect(status.finalityStatus.toString(), matches(RegExp(r'(RECEIVED|REJECTED|ACCEPTED_ON_L2|ACCEPTED_ON_L1)')), + reason: 'Finality status should be one of the expected values'); }, tags: ['integration']); - test('should handle transaction status with only finality_status field', - () async { - expect(successfulTxHash, isNotNull, - reason: 'Previous test must succeed to get a valid transaction hash'); - - final response = await http.post( - devnetUri, - headers: {'Content-Type': 'application/json'}, - body: jsonEncode({ - 'jsonrpc': '2.0', - 'method': 'starknet_getTransactionStatus', - 'params': [successfulTxHash], - 'id': 1, - }), - ); - - final result = jsonDecode(response.body); - expect(result['error'], isNull, - reason: 'Failed to get transaction status'); - - final status = TransactionStatus.fromJson(result['result']); - expect(status.finalityStatus, isNotNull, - reason: 'Transaction status should have a finality status'); - }, tags: ['integration']);Or if there's a meaningful distinction between these tests, clarify it by modifying the second test:
test('should handle transaction status with only finality_status field', () async { expect(successfulTxHash, isNotNull, reason: 'Previous test must succeed to get a valid transaction hash'); final response = await http.post( devnetUri, headers: {'Content-Type': 'application/json'}, body: jsonEncode({ 'jsonrpc': '2.0', 'method': 'starknet_getTransactionStatus', 'params': [successfulTxHash], 'id': 1, }), ); final result = jsonDecode(response.body); expect(result['error'], isNull, reason: 'Failed to get transaction status'); final status = TransactionStatus.fromJson(result['result']); expect(status.finalityStatus, isNotNull, reason: 'Transaction status should have a finality status'); + // Specifically test that the model works even when execution_status is missing + final mockResponseWithoutExecutionStatus = { + 'finality_status': status.finalityStatus.toString() + }; + final partialStatus = TransactionStatus.fromJson(mockResponseWithoutExecutionStatus); + expect(partialStatus.finalityStatus, isNotNull); + expect(partialStatus.executionStatus, isNull); }, tags: ['integration']);Also applies to: 196-219
1-221: Consider refactoring HTTP request logic for DRY principle.The code repeats the pattern of making HTTP requests multiple times. Consider extracting this logic into a helper function to avoid repetition.
Extract a helper function for making HTTP requests:
Future<Map<String, dynamic>> makeRpcRequest( Uri uri, String method, List<dynamic> params, ) async { final response = await http.post( uri, headers: {'Content-Type': 'application/json'}, body: jsonEncode({ 'jsonrpc': '2.0', 'method': method, 'params': params, 'id': 1, }), ); print('Response from $method: ${response.body}'); return jsonDecode(response.body); }Then you can simplify the requests in your tests:
// Get chain ID final chainIdResult = await makeRpcRequest(devnetUri, 'starknet_chainId', []); expect(chainIdResult['error'], isNull, reason: 'Failed to get chain ID'); // Get the latest nonce final nonceResult = await makeRpcRequest( devnetUri, 'starknet_getNonce', ['latest', senderAddress.toHexString()] ); expect(nonceResult['error'], isNull, reason: 'Failed to get nonce');🧰 Tools
🪛 GitHub Actions: CI
[warning] 167-167: The '!' will have no effect because the receiver can't be null. Try removing the '!' operator. - unnecessary_non_null_assertion
🪛 GitHub Actions: code_health
[warning] 167-167: The '!' will have no effect because the receiver can't be null. Try removing the '!' operator. - unnecessary_non_null_assertion
40-169:❓ Verification inconclusive
Fix unnecessary non-null assertions and improve transaction polling.
The test properly sets up a real transaction and checks its status, but there are a couple of improvements needed:
Lines 165 and 167 contain unnecessary non-null assertions (!). Since you already checked that
statusis not null on lines 163-164, Dart's flow analysis knowsstatuscan't be null.The error handling in the polling loop could be improved to provide more context.
Fix the unnecessary non-null assertions:
- expect(status!.finalityStatus, isNotNull, + expect(status.finalityStatus, isNotNull, reason: 'Transaction should have a finality status'); - expect(status!.executionStatus, isNotNull, + expect(status.executionStatus, isNotNull, reason: 'Transaction should have an execution status');Improve error handling in the polling loop:
} catch (e) { - print('Error polling for transaction status: $e'); + print('Error polling for transaction status: $e'); + // Continue polling despite errors }
🏁 Script executed:
#!/bin/bash # Check if the pipeline failure is due to the unnecessary non-null assertions cd packages/starknet_provider dart analyze test/get_transaction_status_test.dartLength of output: 179
Action Required: Manual verification needed for non-null assertions and error handling improvements
The test still requires two updates in the file
packages/starknet_provider/test/get_transaction_status_test.dart:
Remove unnecessary non-null assertions:
Since the check assertingstatusis notnull(around lines 163–164) guarantees that Dart’s flow analysis treatsstatusas non-null, the explicit non-null assertions (status!) on lines 165 and 167 can be safely removed. The diff snippet should be updated as follows:- expect(status!.finalityStatus, isNotNull, + expect(status.finalityStatus, isNotNull, reason: 'Transaction should have a finality status'); - expect(status!.executionStatus, isNotNull, + expect(status.executionStatus, isNotNull, reason: 'Transaction should have an execution status');Improve error handling in the polling loop:
While the current handling prints the error, a comment clarifying that polling continues despite errors would be beneficial. For instance:} catch (e) { - print('Error polling for transaction status: $e'); + print('Error polling for transaction status: $e'); + // Continue polling despite errors }The attempt to verify these changes via the automated
dart analyzecommand was inconclusive due to the environment lacking the Dart tool (dart: command not found). Please perform a manual verification to ensure that these changes remove any analyzer warnings and that the error handling meets the intended improvement.🧰 Tools
🪛 GitHub Actions: CI
[warning] 167-167: The '!' will have no effect because the receiver can't be null. Try removing the '!' operator. - unnecessary_non_null_assertion
🪛 GitHub Actions: code_health
[warning] 167-167: The '!' will have no effect because the receiver can't be null. Try removing the '!' operator. - unnecessary_non_null_assertion
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/starknet_provider/README.md(1 hunks)packages/starknet_provider/test/get_transaction_status_test.dart(1 hunks)
🧰 Additional context used
🪛 GitHub Actions: CI
packages/starknet_provider/test/get_transaction_status_test.dart
[warning] 167-167: The '!' will have no effect because the receiver can't be null. Try removing the '!' operator. - unnecessary_non_null_assertion
🪛 GitHub Actions: code_health
packages/starknet_provider/test/get_transaction_status_test.dart
[warning] 167-167: The '!' will have no effect because the receiver can't be null. Try removing the '!' operator. - unnecessary_non_null_assertion
🔇 Additional comments (3)
packages/starknet_provider/README.md (1)
30-30: Documentation accurately updated to reflect implementation status.The README has been correctly updated to show that
starknet_getTransactionStatusis now implemented (✅). This aligns with the PR objective of implementing this RPC method.packages/starknet_provider/test/get_transaction_status_test.dart (2)
8-18: Well-structured test initialization with clear constants.The constant values for test configuration (polling interval, timeout) are well-defined at the top of the file, making it easy to adjust test parameters. The shared variable for transaction hash is also a good approach for test dependency management.
20-38: Good error case handling for non-existent transaction hash.This test effectively verifies the error response when a non-existent transaction hash is provided. The error code and message assertions are appropriate.
| @freezed | ||
| class TransactionStatus with _$TransactionStatus { | ||
| const factory TransactionStatus({ | ||
| required String finalityStatus, |
There was a problem hiding this comment.
According to JSON RPC SPEC, finalityStatus should be an enum
| class TransactionStatus with _$TransactionStatus { | ||
| const factory TransactionStatus({ | ||
| required String finalityStatus, | ||
| String? executionStatus, |
There was a problem hiding this comment.
According to JSON RPC SPEC, executionStatus should be an enum
| part 'get_transaction_status.g.dart'; | ||
|
|
||
| @freezed | ||
| class TransactionStatus with _$TransactionStatus { |
There was a problem hiding this comment.
It seems that error handling is missing
|
|
||
| /// Gets the status of a transaction by its hash | ||
| /// | ||
| /// [Spec](https://github.com/starkware-libs/starknet-specs/blob/v0.7.0-rc0/api/starknet_api_openrpc.json#L144-L169) |
There was a problem hiding this comment.
Please use permanent link instead
There was a problem hiding this comment.
Your tests should use getTransationStatus method instead of http.post with expected JSON payload.
|
Hi @jaiminRaiyani are you still working on it ? |
nope you can assign this issue to someone else i am not able to solve this with your requested changes |
Add starknet_getTransactionStatus Implementation
Description
This PR adds support for the
starknet_getTransactionStatusRPC method, allowing users to query the status of transactions on the Starknet network. The implementation includes:TransactionStatusmodel with support for:finality_status(RECEIVED, REJECTED, ACCEPTED_ON_L2, ACCEPTED_ON_L1)execution_status(SUCCEEDED, REVERTED)Testing
Implementation Details
get_transaction_status.dartmodel with Freezed annotationsindex.dartfor public accessget_transaction_status_test.dartRelated Issues
Closes #[#468] - Add support for starknet_getTransactionStatus
Checklist
Summary by CodeRabbit
New Features
starknet_getTransactionStatusmethod, including usage examples and expected outcomes.Tests
Chores