Update to Starknet 0.13.4 and 0.13.5 (including RPC 0.8)#697
Update to Starknet 0.13.4 and 0.13.5 (including RPC 0.8)#697
Conversation
* Change L1 hash repr: bytes array and string -> H256
* Move and rename tx status struct; add failure_reason * Rename InsufficientMaxFee to InsufficientResourcesForValidate * Improve panicking_contract: compile with 2.8.0, add method for distant panic
* SimulateTransactions integration tests (#628) * remove handle_transaction_result, refactor errors * integration tests * added new error type * typo * fixed unit tests * fixed integration test * remove fully qualified names in errors file * changed test name * reuse variable * replace declare_deploy_v1 with declare_v3_deploy_v3 * add simulate transaction validation check * add functionality * refactor if else with match * remove trait implementation * changed error variant * commment * resolve compilation errors * fix integration tests * clippy * removed let [skip ci] * removed duplicated method [skip ci] * remove duplicated test [skip ci] * clippy * clippy [skip ci]
* functions for compiling sierra to casm * removed calculate_casm_hash function * added getCompiledCasm endpoint * change used function for compiling FlattenedSierraClass to Casm * integration tests [skip ci] * Reverted changes * clippy * added check in test * change check in test
* Do interval block creation via request
This reverts commit c096337. * [skip ci]
…tion tests (#722) Co-authored-by: FabijanC <fc@spaceshard.io>
There was a problem hiding this comment.
Actionable comments posted: 12
🔭 Outside diff range comments (1)
crates/starknet-devnet-types/src/rpc/contract_class.rs (1)
194-201: 🛠️ Refactor suggestionConsider expanded error info.
TheTransactionVersionor usage might produce advanced errors. Possibly include a more specific enum variant for advanced debugging rather thanConversionError::InvalidFormat.
🧹 Nitpick comments (77)
crates/starknet-devnet-types/src/rpc/emitted_event.rs (1)
12-15: Consider adding documentation for optional fields.While the implementation of optional fields is correct, consider adding documentation that explains when these fields might be
None. This would help API consumers understand the semantics better.#[derive(Serialize, Clone, Debug)] #[cfg_attr(feature = "testing", derive(serde::Deserialize), serde(deny_unknown_fields))] pub struct EmittedEvent { pub transaction_hash: TransactionHash, + /// Hash of the block containing this event. May be None for pending transactions or events not yet included in a block. #[serde(skip_serializing_if = "Option::is_none")] pub block_hash: Option<BlockHash>, + /// Number of the block containing this event. May be None for pending transactions or events not yet included in a block. #[serde(skip_serializing_if = "Option::is_none")] pub block_number: Option<BlockNumber>, pub from_address: ContractAddress, pub keys: Vec<Felt>, pub data: Vec<Felt>, }crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v3.rs (1)
48-50: Add doc comment for clarity.Consider including a short doc comment describing the purpose of
get_resource_boundsfor maintainers reading the code.+ /// Returns a reference to the transaction's resource bounds. pub(crate) fn get_resource_bounds(&self) -> &ResourceBoundsWrapper { &self.resource_bounds }crates/starknet-devnet-types/src/rpc/transaction_receipt.rs (1)
34-34: Consider addingPartialEqandEqif needed.The TODO comment hints at potential benefits for equality checks in tests or comparisons. If such functionality is commonly needed, consider implementing them.
crates/starknet-devnet-types/src/rpc/contract_class.rs (12)
2-4: Check for usage of newly added imports.
Please confirm that all newly imported items (HashMap,FromStr,Arc) are used in the file. If any are unnecessary, consider removing them to keep imports clean.
20-20: Remove stale or unused trait bound references if any.
pub use starknet_rs_core::types::{ ... }under lines 18-20 might be referencing multiple items. Confirm each usage or remove them if not needed.
34-34: Confirm the reason for allowing large enum variants.
Removing#[allow(clippy::large_enum_variant)]might prompt you to restructure the enum to store references or use external data. Consider whether the size is truly necessary.
105-105: Validate contract class fallback.
When converting Cairo 0 classes (line 104-108), ensure edge cases are handled if the legacy contract fails to parse.
130-130: Clarify comment references.
Line 128-129 references Slack conversation aboutabi_length. Copy that rationale into code comments if relevant for future maintainers.
136-136: Keep version alignment in mind.
SierraVersion::DEPRECATEDis used. This suggests older flows. Ensure that the rest of the code does not inadvertently apply the DEPRECATED version to modern classes.
137-138: Iron out internal structure error messages.
Line 139 logs anInvalidInternalStructure. Ensure that the user is provided enough context to debug.
154-155: Version parsing consistency.
SierraVersion::from_str(&sierra_contract_class.contract_class_version)is invoked. Confirm that invalid version strings produce consistent errors.
157-164: Validate error mapping.
Error transitions with.map_err(...)createInvalidInternalStructure(e.to_string()). Make sure there's no loss of detail in error messages that might hamper debugging.
210-217: Unified approach for V2 vs. V3 conversions.
Ensure that the code fully addresses all relevant versions and that partial references to older versions are indeed removed from this code if no longer needed.
308-325: Refine CASM compilation error messaging.
When callingusc::compile_contract(jsonified_sierra), the error isSierraCompilationError { reason: ... }. Consider providing additional context (e.g., the contract name or hash) in error messages to streamline debugging.
379-383: Check naming consistency.
Imports forCairo0Json,ContractClassAbiEntryWithType,DeprecatedContractClass, andContractClasscome from separate submodules. If you want to keep code uniform, consider grouping them or using consistent naming patterns to reduce confusion.crates/starknet-devnet-types/src/rpc/transactions.rs (24)
6-6: Confirm consistency with new versioned constants usage.
use blockifier::versioned_constants::VersionedConstants;is newly introduced. Validate that the code consistently references these constants for all transaction version checks.
12-13: Check for chain ID references.
use starknet_api::block::{BlockNumber, GasPrice};anduse starknet_api::contract_class::{ClassInfo, EntryPointType};might tie to chain ID logic if the code references gas or block data. Ensure alignment with all version checks.
24-24: Double-check parse logic for short strings.
parse_cairo_short_stringcan throw if the string is longer than expected or invalid. Confirm that the code gracefully handles or logs such errors.
44-44: Validate newConversionErrorusage.
Line 44 references expansions toConversionError. Ensure that you handle each possible new variant in calling code.
175-182: Checkget_sender_address()returns.
Ensure each transaction variant either has a legitimate sender or returnsNone(as withDeploy). This helps avoid panics if upstream logic expects a sender for all transactions.
210-217: Enhance clarity in different declare versions.
pub fn get_sender_addressin line 211 references both V2 and V3. Double-check that older versions (e.g., V1) have truly been removed from the code or that they’re not needed anymore.
218-218: Confirm no overlap with older logic.
Line 218 suggests the end of theimpl. Verify that no V1 declare references remain.
431-448: Double-check partial resource combos.
In lines 431-448, logic checks if some resources are zero. Verify that such combinations do not lead to silently ignoring potentially required gas fields.
559-564: Confirm consistent fee checks for declare V2 vs. V3.
Line 560 treats max_fee=0 as invalid for V2, but referencesare_gas_bounds_valid()for V3. Confirm that this difference is intentional and tested.
585-590: Consider extracting the chain ID logic.
You repeatedly callfelt_to_sn_api_chain_id. Factor out if used across multiple transaction creation flows.
640-647: Robust error mapping for paymaster & account deployment data.
When paymaster data is malformed, confirm that the returned error is user-friendly and consistent.
655-664: Validate transaction hash generation for V3.
Thesigned_tx_versioncall could produce edge outcomes if version strings are out of spec. Confirm that the finaltx_hashis correct for the user’s chain ID.
731-753: Inspect concurrency when building deploy account transactions.
Though not typically multi-threaded, any long-living devnet environment could face concurrency. Evaluate if data (likeArc::new(...)calls) is safely shared.
816-831: Look out for large signature arrays.
When buildingInvokeTransactionV1, the signature might be large. Confirm proper bounding or memory usage if many signers are included.
835-841: Validate transaction hash generation for invoke flows.
Line 840 finalizes the transaction hash. Confirm this is consistent with the new version logic (particularly if skipping or adjusting fees).
854-862: Check fallback for unknown versions in declare transaction.
Lines 870-871 error out if the version is invalid. Ensure you have test coverage for that error path.
912-916: Confirm no collision with custom versions.
For invoke transactions, "0x1" and "0x3" are accepted. If custom versions appear, ensure they’re properly validated or flagged.
972-973: ExpandInnerExecutionResourcesif needed.
Currently, it holdsl1_gasandl2_gas. If more resource metrics (e.g., memory usage) become relevant, consider extending or using a more flexible structure.
996-997: Implement typed revert reasons if feasible.
pub revert_reason: Stringcan be replaced with typed errors from blockifier. This might simplify debugging for known error types.
1002-1003: Confirm large variant allowance.
#[allow(clippy::large_enum_variant)]again appears. Evaluate if you can split the largeExecutionInvocationinto smaller data structures.
1014-1015: Fee transfer clarity.
fee_transfer_invocation: Option<FunctionInvocation>can remainNonefor some local test flows. Ensure consistent usage with devnet debug info.
1036-1043: Double-check constructor invocation logic.
When deploying accounts, a constructor invocation might be missing or optional. Make sure the devnet doesn’t incorrectly mark a partial deployment as successful.
1051-1052: Optional state diff for L1Handler.
state_diff: Option<ThinStateDiff>may beNonein certain flows. Consider logging or documenting when that scenario occurs.
1127-1132: Validate revert logic.
is_reverted: call_info.execution.failedmight have side effects if partial successes are possible. Confirm that partial success is not incorrectly flagged as a full revert.crates/starknet-devnet-server/src/lib.rs (1)
10-10: Introduce subscription module carefully.
pub mod subscribe;extends capabilities via WebSocket subscriptions. Make sure new code is tested under concurrency (multiple clients subscribing simultaneously).crates/starknet-devnet-core/src/traits.rs (1)
59-60: Consider resolving the TODO commentThe
#[allow(unused)]annotation with the TODO comment indicates uncertainty about whether this method is only used in tests. Consider:
- Confirming the actual usage
- Moving the method to a test-only module if appropriate
- Removing the comment if the method is needed in production code
This would help maintain code clarity and prevent future confusion about this method's purpose.
crates/starknet-devnet-core/src/starknet/get_class_impls.rs (1)
58-71: Well-implemented new function for CASM retrieval.This function properly handles retrieval and compilation of CASM contract classes for Cairo1 contracts, with appropriate error handling for Cairo0 contracts. Setting
pythonic_hintstoNoneis a good optimization for serialization.One observation: the function always uses the latest block tag, which might restrict its flexibility if retrieval from specific historical blocks is needed in the future.
Consider parameterizing the block ID to allow retrieving CASM classes from specific historical blocks:
-pub fn get_compiled_casm_impl( - starknet: &Starknet, - class_hash: ClassHash, -) -> DevnetResult<CasmContractClass> { - let contract_class = get_class_impl(starknet, &BlockId::Tag(BlockTag::Latest), class_hash)?; +pub fn get_compiled_casm_impl( + starknet: &Starknet, + block_id: &BlockId, + class_hash: ClassHash, +) -> DevnetResult<CasmContractClass> { + let contract_class = get_class_impl(starknet, block_id, class_hash)?;crates/starknet-devnet-core/src/messaging/mod.rs (1)
197-197: Check error message formatting.
While converting H256 to string here is acceptable for logging, consider a hex-prefixed format for clarity.crates/starknet-devnet-core/src/starknet/add_l1_handler_transaction.rs (1)
29-38: Check for potential duplicate entries.
Storing multiple derived L2 transaction hashes for a single L1 hash is valid, but consider whether duplicates might accumulate if transactions are replayed.crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/starknet_write_api.json (1)
1-295: Grammar fix in error message.The key
"CONTRACT_CLASS_SIZE_IS_TOO_LARGE"contains a minor grammatical error:- "message": "Contract class size it too large" + "message": "Contract class size is too large"crates/starknet-devnet-server/src/api/json_rpc/spec_reader/data_generator.rs (1)
242-260: Potential repeated null entries for tuple variants.
If the first recursive attempt generates null, this code retries once with the same depth, which still might yield null and add it to the array anyway. While this is not incorrect, consider whether you want to allow multiple nulls in the final array or if there should be a fallback value or additional attempts.crates/starknet-devnet-core/src/transactions.rs (3)
26-26: Consider carefully exposingStarknetTransactionsoutside the crate.
Transitioning frompub(crate)topubbroadens the external API surface. Ensure this aligns with design goals and does not inadvertently expose internal data.
56-56: Reevaluate visibility ofStarknetTransaction.
Making this struct public allows external crates to instantiate or modify transactions directly. Validate that you’re not unintentionally breaking encapsulation or leaking internal states.
283-288: Broader test coverage recommended.
Introducingdummy_declare_transaction_v3andGasVectorComputationModein tests is a positive step. Consider adding negative/edge cases (e.g., invalid resource bounds or missing versions) to ensure stability.crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/starknet_trace_api_openrpc.json (1)
1-533: Comprehensive OpenRPC specification.
This new file thoroughly defines trace methods and schemas. Two minor tips:
- The
"license": {}field is empty—add relevant license info or remove if not needed.- Verify that each
$refpath is valid and points to an existing definition instarknet_api_openrpc.jsonto avoid broken references.crates/starknet-devnet-core/src/starknet/add_invoke_transaction.rs (3)
18-19: Switch tois_max_fee_validcheck.
Replacing the old fee check withis_max_fee_valid()and returningInsufficientResourcesForValidateclarifies the cause for fee validation failure. Ensure that overlapping checks (e.g., insufficient balance) don’t conflict with this condition.
129-130: TODO aboutExecutionResources.
There’s an inline comment to reduce the parameter count. This might improve readability if you can pass a single struct encapsulating resource data. Consider bundling the execution resources soon to reduce function arity.
230-230:assert!(account.get_balance(...) < initial_balance).
This effectively tests that the fee was deducted. Good practice to confirm the difference is the exact fee charged if you need an even more precise validation.crates/starknet-devnet-core/src/starknet/add_deploy_account_transaction.rs (1)
101-101: Consider addressing this pending TODO.
Additional test coverage for all three gas bounds will ensure robust validation of various resource scenarios.Would you like me to open an issue to track the missing test, or provide a test code snippet?
crates/starknet-devnet-server/src/api/json_rpc/spec_reader/mod.rs (4)
22-26: Avoid overshadowing the standard library'sResulttype.The struct named
Resultcould lead to confusion or collisions, since Rust’sResult<T, E>is a fundamental type. Consider renaming this struct to something likeApiResultorMethodResult.- result: Option<Result>, + result: Option<ApiResult>,
32-35: Clean up or revisit commented-out code.The commented-out serde directive (
#[serde(default)]) may still be relevant or might need removal. If it is no longer necessary, removing it keeps the code tidy; otherwise, clarifying why it's commented out can prevent confusion.
218-221: Validate the case whenmethod.resultisNone.Here,
method.result.as_ref()is mapped togenerate_json_rpc_responseonly when a schema is present. Consider whether aNoneresult should produce a special JSON-RPC response (e.g.,"result": null) or an error.
289-386: Consider reducing complexity inassert_api_request_and_response_are_related.This large match block covers numerous request/response variants. Over time, maintaining it could become cumbersome. Extracting sections into helper methods can improve readability and modularity.
crates/starknet-devnet-core/src/error.rs (2)
144-145: Fee check errors mapped to validation errors.Mapping
MaxGasAmountExceededorMaxFeeExceededtoInsufficientResourcesForValidateis logical. Just confirm there's no scenario in which a more specific error message is needed to aid troubleshooting.
249-320: Conversion fromErrorStackeffectively accumulates call info.The process of traversing stack frames in reverse is a clean way to build nested errors. Consider adding comments explaining how the final structure is formed if new developers might find it non-obvious.
crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/starknet_ws_api.json (4)
1-7: Consider providing a clear license object.The
"license": {}field is currently empty. It is best practice to specify the license details or remove the field if it is not needed.
58-106: Align error naming for event subscription constraints.The method
"starknet_subscribeEvents"references aTOO_MANY_KEYS_IN_FILTERerror, whereas similar constraints (e.g., too many addresses) use different or parallel naming. Consider unifying these names (e.g.,TOO_MANY_X_IN_FILTER) to maintain consistency throughout the API.
234-252: Consider an error for invalid subscription ID.Unlike other subscription-related methods,
"starknet_subscriptionReorg"has no errors listed. If a subscription ID can be invalid or stale, you may want to handle it consistently (e.g., adding theINVALID_SUBSCRIPTION_IDerror) or confirm that it cannot occur in practice.
280-399: Consider extending block tag values and clarifying pending usage.Under
"SUBSCRIPTION_BLOCK_TAG", only"latest"is enumerated. If you intend to support subscribing to"pending"blocks, consider adding it for completeness. Otherwise, clarify why"pending"is excluded. This will reduce confusion for API consumers who expect pending subscriptions to mirror the standard “pending” block semantics.crates/starknet-devnet-core/src/utils.rs (2)
42-46: Avoid or justify usingunwrap.
get_versioned_constants()callsVersionedConstants::get(...).unwrap(). Although you have an#[allow(clippy::unwrap_used)], consider gracefully handling a potentialNonevariant, especially if future versions ofStarknetVersionmight become unavailable.
64-70: Check if macro export is intentional.The
#[macro_export]attribute makesnonzero_gas_price!available to external crates. If this macro is only used internally, consider removing#[macro_export]to avoid polluting the public API. If you need it externally, this is fine.crates/starknet-devnet-server/src/api/json_rpc/models.rs (2)
30-32: Structured input for class hashes.
ClassHashInputis straightforward and consistent. Consider adding documentation to clarify usage or constraints (e.g., size limits).
204-210: Subscription ID usage.Defining
type SubscriptionId = u64;along withSubscriptionIdInputis consistent. Just ensure that you handle overflow or negative ID edge cases in runtime logic if needed.crates/starknet-devnet-server/src/api/json_rpc/endpoints_ws.rs (2)
53-84: Check performance implications of limiting block range to 1024.By returning an error on ranges greater than 1024, any client that needs to resubscribe from farther back will fail. If this limit is intentional, consider documenting or making it configurable.
158-177: Consider concurrency for "socket_context.subscribe".Access to
self.api.sockets.lock()introduces a single concurrency bottleneck. If subscription volume grows, a more granular locking strategy or a concurrent approach might improve performance.crates/starknet-devnet-server/src/api/json_rpc/mod.rs (1)
70-71: Consider clarifying or standardizing error codes.The
ErrorCodein your crate might clash with standard JSON-RPC codes or cause confusion for external consumers. Verify consistency with your error handling approach.crates/starknet-devnet-server/src/subscribe.rs (6)
23-26: Consider potential ID collisions when using a random u64 as a SocketId.Relying on
rand::random()for generating theSocketIdmay theoretically result in collisions, especially over long runtimes or with high throughput. While the probability is low, consider using a more robust approach—such as an atomic counter or a UUID—if guaranteed uniqueness is required.-pub type SocketId = u64; +// Example using a 128-bit random ID, or a globally unique ID approach +use uuid::Uuid; +pub type SocketId = Uuid;
48-54: Consider batching or parallelizing notifications for performance.Iterating through every socket for each notification in two nested loops (
for (_, socket_context) in self.sockets.iter(), thenfor notification in notifications) can become costly if the number of sockets and notifications grows. For high-throughput scenarios, consider dispatching notifications concurrently or batching them to improve scalability.
62-74: Optimize lookup by using a HashSet instead of a Vec.The
AddressFiltercurrently stores addresses in aVec, making.contains(...)an O(n) operation. For larger address filters, switching to aHashSet(orBTreeSetif consistency in ordering is needed) improves performance.#[derive(Debug)] pub struct AddressFilter { - address_container: Vec<ContractAddress>, + address_container: HashSet<ContractAddress>, } impl AddressFilter { pub(crate) fn new(address_container: Vec<ContractAddress>) -> Self { - Self { address_container } + Self { address_container: address_container.into_iter().collect() } } }
76-133: Refactor large match blocks for maintainability.The
Subscription::matchesfunction handles many subscription types within a single match. As the codebase evolves, this block may grow and become harder to maintain. Consider extracting each subscription check into smaller dedicated methods or match arms to improve readability and extensibility.
240-247: Enhance error handling if the WebSocket connection is closed.Currently, if
self.sender.lock().await.send(...)fails, it only logs an error. In production scenarios, consider implementing a reconnection workflow or some cleanup logic (e.g., removing the socket from the collection) to handle closed connections more robustly.
283-322: Consider a non-blocking or batched approach for subscriber notifications.When many subscribers exist, calling
notify(*subscription_id, ...)for each subscription in series can cause a bottleneck. Potential improvements include batching notifications or using an asynchronous queue to avoid blocking even if one subscriber is slow to receive messages.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (107)
.circleci/config.yml(2 hunks)Cargo.toml(3 hunks)contracts/test_artifacts/cairo1/panicking_contract/compilation_info.txt(1 hunks)contracts/test_artifacts/cairo1/panicking_contract/panicking_contract.cairo(1 hunks)contracts/test_artifacts/cairo1/panicking_contract/panicking_contract.sierra(1 hunks)crates/starknet-devnet-core/Cargo.toml(1 hunks)crates/starknet-devnet-core/src/account.rs(7 hunks)crates/starknet-devnet-core/src/blocks/mod.rs(15 hunks)crates/starknet-devnet-core/src/constants.rs(2 hunks)crates/starknet-devnet-core/src/contract_class_choice.rs(2 hunks)crates/starknet-devnet-core/src/error.rs(7 hunks)crates/starknet-devnet-core/src/lib.rs(1 hunks)crates/starknet-devnet-core/src/messaging/ethereum.rs(4 hunks)crates/starknet-devnet-core/src/messaging/mod.rs(4 hunks)crates/starknet-devnet-core/src/raw_execution.rs(0 hunks)crates/starknet-devnet-core/src/starknet/add_declare_transaction.rs(12 hunks)crates/starknet-devnet-core/src/starknet/add_deploy_account_transaction.rs(14 hunks)crates/starknet-devnet-core/src/starknet/add_invoke_transaction.rs(18 hunks)crates/starknet-devnet-core/src/starknet/add_l1_handler_transaction.rs(7 hunks)crates/starknet-devnet-core/src/starknet/defaulter.rs(4 hunks)crates/starknet-devnet-core/src/starknet/estimations.rs(3 hunks)crates/starknet-devnet-core/src/starknet/events.rs(7 hunks)crates/starknet-devnet-core/src/starknet/get_class_impls.rs(3 hunks)crates/starknet-devnet-core/src/starknet/mod.rs(37 hunks)crates/starknet-devnet-core/src/starknet/starknet_config.rs(4 hunks)crates/starknet-devnet-core/src/starknet/state_update.rs(1 hunks)crates/starknet-devnet-core/src/starknet/transaction_trace.rs(6 hunks)crates/starknet-devnet-core/src/state/mod.rs(11 hunks)crates/starknet-devnet-core/src/state/state_diff.rs(7 hunks)crates/starknet-devnet-core/src/state/state_readers.rs(4 hunks)crates/starknet-devnet-core/src/system_contract.rs(1 hunks)crates/starknet-devnet-core/src/traits.rs(1 hunks)crates/starknet-devnet-core/src/transactions.rs(8 hunks)crates/starknet-devnet-core/src/utils.rs(8 hunks)crates/starknet-devnet-server/Cargo.toml(1 hunks)crates/starknet-devnet-server/src/api/http/endpoints/accounts.rs(1 hunks)crates/starknet-devnet-server/src/api/http/endpoints/mint_token.rs(2 hunks)crates/starknet-devnet-server/src/api/json_rpc/endpoints.rs(11 hunks)crates/starknet-devnet-server/src/api/json_rpc/endpoints_ws.rs(1 hunks)crates/starknet-devnet-server/src/api/json_rpc/error.rs(14 hunks)crates/starknet-devnet-server/src/api/json_rpc/mod.rs(18 hunks)crates/starknet-devnet-server/src/api/json_rpc/models.rs(4 hunks)crates/starknet-devnet-server/src/api/json_rpc/spec_reader/data_generator.rs(6 hunks)crates/starknet-devnet-server/src/api/json_rpc/spec_reader/mod.rs(4 hunks)crates/starknet-devnet-server/src/api/json_rpc/spec_reader/spec_modifier.rs(5 hunks)crates/starknet-devnet-server/src/api/json_rpc/spec_reader/spec_schemas/array_primitive.rs(1 hunks)crates/starknet-devnet-server/src/api/json_rpc/spec_reader/spec_schemas/integer_primitive.rs(1 hunks)crates/starknet-devnet-server/src/api/json_rpc/spec_reader/spec_schemas/mod.rs(3 hunks)crates/starknet-devnet-server/src/api/json_rpc/spec_reader/spec_schemas/tuple_schema.rs(1 hunks)crates/starknet-devnet-server/src/api/json_rpc/write_endpoints.rs(2 hunks)crates/starknet-devnet-server/src/api/mod.rs(2 hunks)crates/starknet-devnet-server/src/lib.rs(1 hunks)crates/starknet-devnet-server/src/rpc_core/response.rs(1 hunks)crates/starknet-devnet-server/src/rpc_handler.rs(3 hunks)crates/starknet-devnet-server/src/server.rs(1 hunks)crates/starknet-devnet-server/src/subscribe.rs(1 hunks)crates/starknet-devnet-server/src/test_utils.rs(0 hunks)crates/starknet-devnet-server/test_data/rpc/declare_v1.json(0 hunks)crates/starknet-devnet-server/test_data/spec/0.7.1/starknet_trace_api_openrpc.json(0 hunks)crates/starknet-devnet-server/test_data/spec/0.7.1/starknet_write_api.json(0 hunks)crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/edit_spec_instructions.yaml(3 hunks)crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/starknet_executables.json(1 hunks)crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/starknet_trace_api_openrpc.json(1 hunks)crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/starknet_write_api.json(1 hunks)crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/starknet_ws_api.json(1 hunks)crates/starknet-devnet-types/Cargo.toml(0 hunks)crates/starknet-devnet-types/src/constants.rs(0 hunks)crates/starknet-devnet-types/src/lib.rs(1 hunks)crates/starknet-devnet-types/src/rpc/block.rs(4 hunks)crates/starknet-devnet-types/src/rpc/contract_class.rs(8 hunks)crates/starknet-devnet-types/src/rpc/contract_class/deprecated/json_contract_class.rs(4 hunks)crates/starknet-devnet-types/src/rpc/contract_class/deprecated/mod.rs(2 hunks)crates/starknet-devnet-types/src/rpc/contract_class/deprecated/rpc_contract_class.rs(3 hunks)crates/starknet-devnet-types/src/rpc/emitted_event.rs(2 hunks)crates/starknet-devnet-types/src/rpc/estimate_message_fee.rs(3 hunks)crates/starknet-devnet-types/src/rpc/gas_modification.rs(3 hunks)crates/starknet-devnet-types/src/rpc/messaging.rs(1 hunks)crates/starknet-devnet-types/src/rpc/transaction_receipt.rs(3 hunks)crates/starknet-devnet-types/src/rpc/transactions.rs(27 hunks)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v1.rs(0 hunks)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v2.rs(4 hunks)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v3.rs(2 hunks)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_deploy_account_transaction_v1.rs(3 hunks)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_deploy_account_transaction_v3.rs(0 hunks)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_invoke_transaction_v1.rs(3 hunks)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_invoke_transaction_v3.rs(2 hunks)crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v0v1.rs(0 hunks)crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v2.rs(1 hunks)crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v3.rs(3 hunks)crates/starknet-devnet-types/src/rpc/transactions/deploy_account_transaction_v1.rs(1 hunks)crates/starknet-devnet-types/src/rpc/transactions/deploy_account_transaction_v3.rs(2 hunks)crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v1.rs(1 hunks)crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v3.rs(3 hunks)crates/starknet-devnet-types/src/rpc/transactions/l1_handler_transaction.rs(7 hunks)crates/starknet-devnet-types/src/utils.rs(3 hunks)crates/starknet-devnet-types/test_data/sequencer_response/declare_v3_integration_0x41d1f5206ef58a443e7d3d1ca073171ec25fa75313394318fc83a074a6631c3.json(0 hunks)crates/starknet-devnet-types/test_data/sequencer_response/deploy_account_v3_integration_0x29fd7881f14380842414cdfdd8d6c0b1f2174f8916edcfeb1ede1eb26ac3ef0.json(0 hunks)crates/starknet-devnet-types/test_data/sequencer_response/invoke_v3_integration_0x41906f1c314cca5f43170ea75d3b1904196a10101190d2b12a41cc61cfd17c.json(0 hunks)crates/starknet-devnet/Cargo.toml(1 hunks)crates/starknet-devnet/src/cli.rs(3 hunks)crates/starknet-devnet/src/main.rs(5 hunks)docker/Dockerfile(2 hunks)rust-toolchain.toml(1 hunks)tests/integration/Cargo.toml(2 hunks)tests/integration/common/background_devnet.rs(6 hunks)tests/integration/common/constants.rs(2 hunks)tests/integration/common/errors.rs(2 hunks)
⛔ Files not processed due to max files limit (28)
- tests/integration/common/fees.rs
- tests/integration/common/utils.rs
- tests/integration/general_integration_tests.rs
- tests/integration/general_rpc_tests.rs
- tests/integration/get_transaction_by_block_id_and_index.rs
- tests/integration/get_transaction_by_hash.rs
- tests/integration/get_transaction_receipt_by_hash.rs
- tests/integration/lib.rs
- tests/integration/test_abort_blocks.rs
- tests/integration/test_account_impersonation.rs
- tests/integration/test_account_selection.rs
- tests/integration/test_advancing_time.rs
- tests/integration/test_balance.rs
- tests/integration/test_blocks_generation.rs
- tests/integration/test_call.rs
- tests/integration/test_dump_and_load.rs
- tests/integration/test_estimate_fee.rs
- tests/integration/test_estimate_message_fee.rs
- tests/integration/test_fork.rs
- tests/integration/test_gas_modification.rs
- tests/integration/test_get_class.rs
- tests/integration/test_get_events.rs
- tests/integration/test_messaging.rs
- tests/integration/test_minting.rs
- tests/integration/test_old_state.rs
- tests/integration/test_restart.rs
- tests/integration/test_simulate_transactions.rs
- tests/integration/test_subscription_to_blocks.rs
💤 Files with no reviewable changes (13)
- crates/starknet-devnet-types/Cargo.toml
- crates/starknet-devnet-server/src/test_utils.rs
- crates/starknet-devnet-core/src/raw_execution.rs
- crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v0v1.rs
- crates/starknet-devnet-types/src/constants.rs
- crates/starknet-devnet-server/test_data/rpc/declare_v1.json
- crates/starknet-devnet-server/test_data/spec/0.7.1/starknet_trace_api_openrpc.json
- crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v1.rs
- crates/starknet-devnet-types/test_data/sequencer_response/invoke_v3_integration_0x41906f1c314cca5f43170ea75d3b1904196a10101190d2b12a41cc61cfd17c.json
- crates/starknet-devnet-types/test_data/sequencer_response/deploy_account_v3_integration_0x29fd7881f14380842414cdfdd8d6c0b1f2174f8916edcfeb1ede1eb26ac3ef0.json
- crates/starknet-devnet-types/test_data/sequencer_response/declare_v3_integration_0x41d1f5206ef58a443e7d3d1ca073171ec25fa75313394318fc83a074a6631c3.json
- crates/starknet-devnet-types/src/rpc/transactions/broadcasted_deploy_account_transaction_v3.rs
- crates/starknet-devnet-server/test_data/spec/0.7.1/starknet_write_api.json
🧰 Additional context used
🧬 Code Definitions (30)
crates/starknet-devnet-server/src/lib.rs (1)
crates/starknet-devnet-server/src/subscribe.rs (1)
subscribe(249-263)
crates/starknet-devnet-types/src/lib.rs (1)
crates/starknet-devnet-types/src/utils.rs (2)
compile_sierra_contract(90-95)compile_sierra_contract_json(97-105)
crates/starknet-devnet-server/src/api/json_rpc/write_endpoints.rs (1)
crates/starknet-devnet-server/src/test_utils.rs (1)
deploy_account_str(3-9)
crates/starknet-devnet-server/src/server.rs (1)
crates/starknet-devnet-server/src/rpc_handler.rs (1)
handle_socket(60-70)
crates/starknet-devnet-core/src/contract_class_choice.rs (1)
crates/starknet-devnet-types/src/rpc/contract_class.rs (1)
contract_class(288-292)
crates/starknet-devnet-types/src/rpc/transactions/broadcasted_deploy_account_transaction_v1.rs (2)
crates/starknet-devnet-core/src/starknet/mod.rs (1)
chain_id(794-796)crates/starknet-devnet-server/src/api/json_rpc/endpoints.rs (1)
chain_id(388-392)
crates/starknet-devnet-types/src/rpc/contract_class/deprecated/mod.rs (1)
crates/starknet-devnet-types/src/rpc/contract_class.rs (1)
contract_class(288-292)
crates/starknet-devnet-core/src/transactions.rs (3)
crates/starknet-devnet-core/src/utils.rs (1)
dummy_declare_transaction_v3(146-164)crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v3.rs (1)
new(33-48)crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v3.rs (1)
new(32-46)
crates/starknet-devnet-core/src/starknet/estimations.rs (4)
crates/starknet-devnet-core/src/starknet/mod.rs (4)
transactions(1255-1286)should_transaction_skip_validation_if_sender_is_impersonated(1466-1492)chain_id(794-796)block(1055-1064)crates/starknet-devnet-types/src/rpc/transactions.rs (4)
gas_vector_computation_mode(106-115)gas_vector_computation_mode(528-541)from(346-352)from(396-424)crates/starknet-devnet-core/src/error.rs (8)
from(84-86)from(116-138)from(142-151)from(155-175)from(217-219)from(226-229)from(251-319)from(323-368)crates/starknet-devnet-core/src/utils.rs (1)
get_versioned_constants(43-46)
crates/starknet-devnet-types/src/rpc/transaction_receipt.rs (4)
crates/starknet-devnet-core/src/transactions.rs (1)
get_block_number(226-228)crates/starknet-devnet-types/src/rpc/transactions.rs (2)
from(346-352)from(396-424)crates/starknet-devnet-core/src/starknet/starknet_config.rs (1)
value(52-53)crates/starknet-devnet-server/src/api/json_rpc/spec_reader/spec_modifier.rs (1)
value(84-84)
crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v3.rs (2)
crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v3.rs (1)
get_resource_bounds(48-50)crates/starknet-devnet-types/src/rpc/transactions/deploy_account_transaction_v3.rs (1)
get_resource_bounds(60-62)
crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v2.rs (1)
crates/starknet-devnet-types/src/chain_id.rs (1)
goerli_legacy_id(29-31)
crates/starknet-devnet-types/src/utils.rs (2)
crates/starknet-devnet-types/src/rpc/contract_class.rs (3)
contract_class(288-292)serde_json(315-315)serde_json(469-469)crates/starknet-devnet-server/src/api/json_rpc/mod.rs (4)
serde_json(987-987)serde_json(1149-1149)serde_json(1575-1575)serde_json(1579-1579)
crates/starknet-devnet-core/src/account.rs (4)
crates/starknet-devnet-types/src/rpc/contract_class.rs (4)
contract_class(288-292)from(62-64)from(68-70)from(74-76)crates/starknet-devnet-types/src/rpc/felt.rs (3)
felt_from_prefixed_hex(21-30)join_felts(15-19)split_biguint(7-12)crates/starknet-devnet-core/src/utils.rs (2)
get_storage_var_address(31-40)dummy_cairo_1_contract_class(103-109)crates/starknet-devnet-core/src/state/state_diff.rs (1)
from(126-176)
crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v3.rs (2)
crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v3.rs (1)
get_resource_bounds(54-56)crates/starknet-devnet-types/src/rpc/transactions/deploy_account_transaction_v3.rs (1)
get_resource_bounds(60-62)
crates/starknet-devnet-types/src/rpc/contract_class.rs (3)
crates/starknet-devnet-types/src/utils.rs (2)
compile_sierra_contract(90-95)serde_json(103-103)crates/starknet-devnet-types/src/rpc/contract_class/deprecated/json_contract_class.rs (2)
try_from(221-233)try_from(239-242)crates/starknet-devnet-types/src/rpc/contract_class/deprecated/rpc_contract_class.rs (1)
try_from(90-93)
crates/starknet-devnet-core/src/error.rs (3)
crates/starknet-devnet-core/src/state/state_diff.rs (1)
from(126-176)crates/starknet-devnet-core/src/messaging/ethereum.rs (3)
from(57-59)from(63-65)new(87-126)crates/starknet-devnet-core/src/starknet/mod.rs (1)
new(160-294)
crates/starknet-devnet/src/main.rs (4)
crates/starknet-devnet-server/src/api/json_rpc/mod.rs (5)
serde_json(987-987)serde_json(1149-1149)serde_json(1575-1575)serde_json(1579-1579)new(256-275)crates/starknet-devnet-server/src/api/json_rpc/models.rs (5)
serde_json(292-292)serde_json(387-387)serde_json(401-401)serde_json(424-424)serde_json(581-581)crates/starknet-devnet-server/src/dump_util.rs (1)
dump_events(13-21)crates/starknet-devnet-server/src/api/json_rpc/origin_forwarder.rs (1)
new(24-26)
crates/starknet-devnet-core/src/starknet/add_declare_transaction.rs (4)
crates/starknet-devnet-core/src/starknet/estimations.rs (1)
transactions(34-52)crates/starknet-devnet-types/src/utils.rs (1)
compile_sierra_contract(90-95)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v2.rs (1)
new(22-42)crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v3.rs (1)
new(33-48)
crates/starknet-devnet-server/src/api/json_rpc/endpoints.rs (5)
crates/starknet-devnet-server/src/rpc_core/response.rs (2)
error(43-45)error(66-68)crates/starknet-devnet-core/src/starknet/mod.rs (1)
get_compiled_casm(691-693)crates/starknet-devnet-server/src/api/json_rpc/mod.rs (2)
from(1018-1020)from(1024-1026)crates/starknet-devnet-core/src/blocks/mod.rs (2)
from(204-260)from(264-323)crates/starknet-devnet-core/src/error.rs (6)
from(84-86)from(116-138)from(142-151)from(155-175)from(217-219)from(226-229)
crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v3.rs (4)
crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v2.rs (1)
new(22-42)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_deploy_account_transaction_v1.rs (1)
new(20-40)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_invoke_transaction_v1.rs (1)
new(18-36)crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v3.rs (1)
new(33-48)
crates/starknet-devnet-core/src/starknet/mod.rs (6)
crates/starknet-devnet-core/src/starknet/estimations.rs (1)
transactions(34-52)crates/starknet-devnet-types/src/rpc/transactions.rs (6)
gas_vector_computation_mode(106-115)gas_vector_computation_mode(528-541)new(127-129)new(359-383)from(346-352)from(396-424)crates/starknet-devnet-core/src/starknet/transaction_trace.rs (1)
create_trace(73-149)crates/starknet-devnet-core/src/starknet/get_class_impls.rs (1)
get_compiled_casm_impl(58-71)crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v3.rs (1)
new(32-46)crates/starknet-devnet-core/src/starknet/events.rs (1)
get_events(21-87)
crates/starknet-devnet-types/src/rpc/contract_class/deprecated/rpc_contract_class.rs (1)
crates/starknet-devnet-types/src/rpc/contract_class.rs (1)
contract_class(288-292)
crates/starknet-devnet-types/src/rpc/block.rs (5)
crates/starknet-devnet-types/src/rpc/transactions.rs (5)
deserialize(850-873)deserialize(877-900)deserialize(904-927)from(346-352)from(396-424)crates/starknet-devnet-core/src/blocks/mod.rs (2)
from(204-260)from(264-323)crates/starknet-devnet-core/src/starknet/starknet_config.rs (1)
value(52-53)crates/starknet-devnet-server/src/api/json_rpc/models.rs (9)
serde_json(292-292)serde_json(387-387)serde_json(401-401)serde_json(424-424)serde_json(581-581)serde_json(594-594)serde_json(607-607)serde_json(623-623)serde_json(636-636)crates/starknet-devnet-server/src/api/json_rpc/spec_reader/mod.rs (1)
serde_json(277-277)
crates/starknet-devnet-core/src/state/mod.rs (4)
crates/starknet-devnet-core/src/state/state_readers.rs (1)
get_compiled_class(51-56)crates/starknet-devnet-core/src/starknet/defaulter.rs (2)
get_compiled_class(143-149)get_compiled_class(217-235)crates/starknet-devnet-core/src/utils.rs (1)
dummy_cairo_1_contract_class(103-109)crates/starknet-devnet-core/src/starknet/starknet_config.rs (1)
default(144-177)
crates/starknet-devnet-types/src/rpc/transactions.rs (5)
crates/starknet-devnet-types/src/rpc/transaction_receipt.rs (1)
from(84-90)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v3.rs (1)
from(23-25)crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v3.rs (2)
from(54-70)new(32-46)crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v3.rs (1)
new(33-48)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_invoke_transaction_v3.rs (1)
create_sn_api_invoke(22-45)
crates/starknet-devnet-core/src/starknet/add_invoke_transaction.rs (6)
crates/starknet-devnet-core/src/error.rs (8)
from(84-86)from(116-138)from(142-151)from(155-175)from(217-219)from(226-229)from(251-319)from(323-368)crates/starknet-devnet-core/src/starknet/mod.rs (1)
new(160-294)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_invoke_transaction_v1.rs (1)
new(18-36)crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v3.rs (1)
new(32-46)crates/starknet-devnet-core/src/state/state_diff.rs (1)
setup(374-376)crates/starknet-devnet-core/src/traits.rs (1)
get_balance(60-60)
crates/starknet-devnet-server/src/api/json_rpc/mod.rs (5)
crates/starknet-devnet-server/src/api/json_rpc/models.rs (9)
serde_json(292-292)serde_json(387-387)serde_json(401-401)serde_json(424-424)serde_json(581-581)serde_json(594-594)serde_json(607-607)serde_json(623-623)serde_json(636-636)crates/starknet-devnet-server/src/api/json_rpc/spec_reader/mod.rs (1)
serde_json(277-277)crates/starknet-devnet-server/src/rpc_handler.rs (2)
on_call(37-37)on_websocket(40-40)crates/starknet-devnet-server/src/rpc_core/request.rs (1)
id(26-28)crates/starknet-devnet-server/src/rpc_core/error.rs (2)
method_not_found(30-32)invalid_params(45-50)
crates/starknet-devnet-core/src/utils.rs (3)
crates/starknet-devnet-core/src/starknet/mod.rs (3)
block(1055-1064)new(160-294)transactions(1255-1286)crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v2.rs (1)
new(22-42)crates/starknet-devnet-types/src/utils.rs (1)
compile_sierra_contract(90-95)
crates/starknet-devnet-server/src/subscribe.rs (6)
crates/starknet-devnet-core/src/starknet/events.rs (1)
check_if_filter_applies_for_event(95-106)crates/starknet-devnet-server/src/rpc_core/response.rs (1)
new(19-21)crates/starknet-devnet-server/src/api/mod.rs (1)
new(24-30)crates/starknet-devnet-types/src/rpc/transactions.rs (2)
new(127-129)new(359-383)crates/starknet-devnet-server/src/api/json_rpc/spec_reader/data_generator.rs (1)
new(52-54)crates/starknet-devnet-server/src/api/json_rpc/models.rs (9)
serde_json(292-292)serde_json(387-387)serde_json(401-401)serde_json(424-424)serde_json(581-581)serde_json(594-594)serde_json(607-607)serde_json(623-623)serde_json(636-636)
🔇 Additional comments (438)
crates/starknet-devnet-types/src/rpc/transactions/deploy_account_transaction_v1.rs (2)
2-2: Update ImportedFeePath
The import forFeehas been updated to use the new namespace (starknet_api::transaction::fields::Fee). This change aligns with the revamped module structure in the Starknet API. Make sure that any other parts of the codebase relying on the old path have been similarly updated.
1-49: Overall Structure Review
The remainder of the file—including the struct definition and its implementation—is clean and consistent. Although the AI summary mentioned an update to a deploy account transaction creation method (switching from.create_blockifier_deploy_account(&chain_id, false)to.create_sn_api_deploy_account(&chain_id)), no such invocation is present in this file. Please confirm that any related test functions or upstream calls reflect this change appropriately.crates/starknet-devnet-types/src/rpc/emitted_event.rs (2)
12-15: Approve making block-related fields optional with serialization control.The change to make
block_hashandblock_numberoptional fields with serialization control is appropriate as it increases flexibility in representing events, particularly those not yet associated with a block (like those from pending transactions).
47-55: Good implementation of the From trait.This implementation follows Rust best practices by providing a clean conversion from
&EmittedEventtoEvent. The implementation properly handles the field copies and follows the idiomatic pattern for implementing conversion traits.crates/starknet-devnet-types/src/rpc/transactions/l1_handler_transaction.rs (8)
8-9: Good job updating imports for SN API transition.These imports reflect the transition from blockifier to the new SN API, which is aligned with the PR objectives of updating to Starknet 0.13.4.
14-14: Import update for the new transaction hash field.This import correctly adds the
Hash256type, which is needed for the new field tracking L1 transaction hashes.
26-28: Well-documented new field for L1 transaction tracking.The new field is properly documented, clearly explaining its purpose and when it might be omitted. Using
Option<Hash256>is appropriate for this optional field.
64-69: Good method rename and implementation for SN API transition.The method has been appropriately renamed from
create_blockifier_transactiontocreate_sn_api_transactionto reflect the transition to the new SN API. The return type is also updated accordingly.
108-109: Proper field initialization in transaction conversion.The new field is correctly initialized from the message parameter, and the version is explicitly set with a helpful comment about version support.
127-127: Consistent field handling in reverse conversion.The field is properly propagated when converting from a transaction back to a message, maintaining data consistency.
164-164: Test case updated for new field.The test correctly initializes the new field to
None, which is appropriate for testing the optional field.
204-204: Updated chain ID reference in test assertion.The test now uses the
ChainId::goerli_legacy_id()method instead of a variable, which is a good practice for maintaining consistency across the codebase.crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/edit_spec_instructions.yaml (13)
7-7: Clarify Section Naming: “replace_property” Key
The key has been renamed to replace_property, which more explicitly indicates that only specific properties (rather than complete objects) will be targeted for replacement. Please ensure that all downstream YAML consumers and processing scripts are updated to expect this new key name.
11-14: Schema Update: Mapping Properties to “tuple”
The modifications for the schemas under CASM_COMPILED_CONTRACT_CLASS (at/properties/hints/items/oneOf) and DoubleDeref (at/properties/DoubleDeref/oneOf) now assign a new name of tuple. Verify that this change is aligned with the intended schema evolution and that any client code or downstream processing that depends on these definitions will correctly interpret the new type.
19-19: Addition of “replace_mode” Flag
The addition ofreplace_mode: trueunder the NUM_AS_HEX schema entry suggests a change in how replacements are handled. Please confirm that the processing logic interprets this flag appropriately and that any related documentation is updated accordingly.
50-51: Review Removal in HINT Schema
The removal of the element at index 0 fromcomponents/schemas/HINT/oneOfhas been introduced here. Ensure that this removal is intentional, that it does not inadvertently eliminate required schema data, and that consumers of the spec are updated to reflect this change.
56-57: Enforce Required Field: “execution_status”
The change to add execution_status to theTXN_STATUS_RESULT.requiredarray ensures proper validation of transaction statuses. Please verify that all dependent systems (including tests and client code) have been updated and that documentation reflects this requirement.
58-59: Addition of “abi” to CONTRACT_CLASS Requirements
Including abi in the required fields ofCONTRACT_CLASSwill enforce a more comprehensive contract schema. Confirm that this change is synchronized with both upstream contract definitions and client expectations, and update any relevant documentation or tests.
61-62: Removal: Exclusion of a SYNC_STATUS Variant
The removal of thestarknet_syncing -> result -> oneOf SYNC_STATUS variantmay affect clients expecting the variant. Double-check that all integrations and documentation account for this removal and that fallback behavior (if any) is adequately supported.
67-68: Schema Simplification: CASM_COMPILED_CONTRACT_CLASS.hints
Removing the outer object from thehintsproperty simplifies the schema forCASM_COMPILED_CONTRACT_CLASS. Verify that this streamlined structure is correctly handled across all processing components and that tests confirm the expected behavior.
70-71: Schema Simplification: DoubleDeref.hints
Likewise, the removal of the outer object in theDoubleDeref.hintsproperty is intended to simplify its structure. Please check that this change is propagated throughout the codebase and that any consuming logic or tests are updated accordingly.
73-74: Addition: Constraining DoubleDeref Tuple Values
Introducing a maximum constraint (32767) for the integer part of the DoubleDeref tuple provides clear boundary enforcement. Verify that this constraint is in line with the expected input range and that boundary conditions are properly tested and documented.
75-76: Streamlining Schema for starknet_simulateTransactions
The removal of the outer “schema” object in favor of a more direct structure (items → {type, properties}) within starknet_simulateTransactions represents a notable schema simplification. Ensure that client parsing logic is updated accordingly and that this change is clearly communicated as breaking.
82-83: Removal: Adjusting REORG_DATA Schema Structure
The removal of the outer schema object forREORG_DATA.starting_block_hashandREORG_DATA.ending_block_hashin the starknet_ws_api spec may impact how reorganization data is parsed. Confirm that this change is intentional and that all downstream dependencies are aware of the update.
84-85: Regex Update: FELT Pattern Constraint
The regex pattern for components/schemas/FELT has been updated to:^0x(0|[a-fA-F1-9]{1}[a-fA-F0-9]{0,61})$This new expression appears to be more strict, which can help prevent invalid values but may also exclude edge cases if not thoroughly vetted. Please verify that the updated regex fully encompasses the valid range of inputs and matches the intended specification.
contracts/test_artifacts/cairo1/panicking_contract/compilation_info.txt (1)
1-1: Cairo Compiler Version Update Verified
The file now indicates that it’s compiled using Cairo 2.8.0. Ensure that any changes in compiler behavior or new features in Cairo 2.8.0 have been tested against your contract’s expected behavior.rust-toolchain.toml (1)
1-3: Rust Toolchain Version Upgrade
The channel has been updated from 1.76.0 to 1.83.0. This update should align with downstream changes (e.g., in CI/CD and Docker images) and is necessary for compatibility with new components. Please verify that all the Rust dependencies compile correctly with the upgraded toolchain.tests/integration/Cargo.toml (2)
19-21: Addition offuturesDependency
Thefutures = { workspace = true }dependency was added at line 20. Verify that the workspace-managed version is consistent with other parts of the project and that it’s actually required by the integration tests.
33-35: Addition oftokio-tungsteniteDependency
Thetokio-tungstenite = { workspace = true }dependency is now included (line 34). Ensure this dependency is compatible with your current Tokio version and integrated seamlessly into the asynchronous test setups.crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v1.rs (1)
1-2: Updated Import forFeeType
The import forFeehas been modified fromstarknet_api::transaction::Feetostarknet_api::transaction::fields::Fee. This refactor clarifies the module structure. Make sure all references toFeein related transaction modules are updated accordingly.docker/Dockerfile (2)
1-1: Rust Builder Image Update
The base image for the builder stage has changed torust:1.83.0-slim-bullseye. This update ensures that the build environment matches the upgraded toolchain. Confirm that your build dependencies are compatible with Bullseye.
11-12: Final Image Base Update
The final image now usesdebian:bullseye-sliminstead ofbuster-slim. This change aligns the runtime environment with the builder stage and the updated CI configuration. Verify that all runtime dependencies (such as libraries or system packages) are available and compatible with Bullseye.crates/starknet-devnet-server/src/api/json_rpc/write_endpoints.rs (2)
171-172: Check concurrency safety when clearing sockets.Clearing the sockets upon restart might disrupt ongoing connections if there are concurrent operations. Consider ensuring that no long-running tasks depend on these sockets mid-restart.
194-195: Confirm necessity of these new imports.These new imports are valid if the corresponding structures and functions are used in new tests. If they're no longer required, consider removing them to keep imports concise.
crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v3.rs (2)
3-3: Ensure the correct import path forTip.Shifting
Tipintostarknet_api::transaction::fieldsis presumably in sync with the new library structure. Looks good.
27-27: Reevaluate broader visibility requirement.Marking
sender_addressaspub(crate)might be necessary to allow usage across modules. Ensure it doesn’t unintentionally expose sensitive data.contracts/test_artifacts/cairo1/panicking_contract/panicking_contract.sierra (1)
1-1: Validate updated contract elements and new function usage.The contract’s entire content appears replaced, introducing new fields and the
create_panic_in_another_contractfunction. Confirm that relevant tests validate this functionality to ensure contract stability.contracts/test_artifacts/cairo1/panicking_contract/panicking_contract.cairo (5)
1-2: Update to imports reflects added functionalityThe import of
ContractAddressfrom the core Starknet module is now used by the newcreate_panic_in_another_contractmethod, allowing cross-contract communication.
6-6: New method added to enable cross-contract panicsThis new method in the
IPanickingContracttrait properly extends the contract's functionality to enable creating panics in other contracts by specifying both the target contract address and the panic reason.
11-12: Expanded imports for cross-contract functionalityThe module now imports both
ContractAddressandcall_contract_syscallfrom core Starknet, which are necessary for the new functionality to call methods in other contracts.
16-16: ABI annotation format updatedThe change from
#[external(v0)]to#[abi(embed_v0)]reflects an update in the Cairo language syntax for ABI specification, which is consistent with the Starknet 0.13.4 update.
21-28: Implementation of cross-contract panic creationThe new method correctly implements the functionality defined in the trait, using
call_contract_syscallto invoke thecreate_panicmethod on another contract. The implementation:
- Takes target contract address and panic reason
- Uses the
selector!macro to specify the method name- Passes the panic reason as an argument
- Correctly unwraps the result
This implementation aligns with the Starknet cross-contract call patterns.
crates/starknet-devnet-types/src/rpc/transactions/broadcasted_deploy_account_transaction_v1.rs (3)
2-2: Updated import path for Fee typeThe import path for
Feehas been changed fromstarknet_api::transaction::Feetostarknet_api::transaction::fields::Fee, reflecting a structural reorganization in the Starknet API library that aligns with the 0.13.4 update.
46-46: Updated test module import path for FeeConsistent with the main module, the import path for
Feein the test module has also been updated tostarknet_api::transaction::fields::Fee.
95-95: Method name change from blockifier to sn_apiThe method call has been changed from
.create_blockifier_deploy_account()to.create_sn_api_deploy_account(), which reflects the transition from blockifier to the Starknet API as part of the 0.13.4 update. This change is consistent with the PR's objective of updating to the latest Starknet API.crates/starknet-devnet-types/src/utils.rs (5)
3-9: Updated imports for Sierra contract compilationAdded imports for
CasmContractClassandContractClassfrom the Cairo language Starknet classes module, and updated error imports. These changes support the new Sierra contract compilation functionality added to this file.
90-95: New utility function to compile Sierra contractsThe
compile_sierra_contractfunction is a valuable addition that:
- Takes a reference to a
ContractClass- Converts it to a JSON value
- Passes it to
compile_sierra_contract_json- Properly handles errors with appropriate mapping
This function will simplify contract compilation workflows in the project.
97-105: Added JSON-based Sierra contract compilation functionThe
compile_sierra_contract_jsonfunction:
- Takes a JSON representation of a Sierra contract
- Uses the Universal Sierra Compiler (USC) to compile it
- Converts the result to a
CasmContractClass- Handles errors appropriately
This function provides flexibility by accepting JSON directly, making it useful for various integration scenarios.
107-117: Simplified test utils moduleThe test utils module has been simplified, removing several constants while retaining the
CAIRO_0_ACCOUNT_CONTRACT_HASHconstant. This change aligns with the broader refactoring in the codebase for the Starknet 0.13.4 update.
183-184: Simplified conditional expressionThe conditional expression in the call to
traverse_and_exclude_recursivelyhas been simplified by removing unnecessary line breaks, making the code more concise and readable.crates/starknet-devnet-types/src/rpc/estimate_message_fee.rs (3)
5-6: Updated imports for L1HandlerTransaction and CalldataThe imports have been updated to use
starknet_api::executable_transaction::L1HandlerTransactionandstarknet_api::transaction::fields::Calldata, reflecting the reorganization of the Starknet API library structure in version 0.13.4.
19-24: Enhanced fee estimation with L1/L2 gas metricsThe
FeeEstimateWrapperhas been significantly improved by:
- Renaming fields to clarify their purpose (prefix with 'l1_')
- Adding new fields for L2 gas metrics (
l2_gas_consumedandl2_gas_price)This change provides more granular insights into gas consumption across L1 and L2, which is valuable for accurate fee estimation and aligns with Starknet 0.13.4's enhanced fee model.
76-76: Updated Fee namespace in L1 transaction creationThe
paid_fee_on_l1field now usesstarknet_api::transaction::fields::Feeinstead ofstarknet_api::transaction::Fee, consistent with the namespace changes in Starknet API 0.13.4.crates/starknet-devnet-types/src/rpc/transaction_receipt.rs (4)
1-3: Imports look good.The additional
serdeimports forDeserializeandSerialize, and the switch tostarknet_api::transaction::fields::Feeappear consistent and correct.
21-32: Functionality to extract block number is clear.
get_block_numbercleanly maps theBlockNumber(n)intoOption<u64>. This approach is straightforward and should not pose issues as long as the usage site acknowledges the possibility ofNone.
78-80: Refactored resource fields are clear.Renaming or merging resource fields into
l1_gas,l1_data_gas, andl2_gasis simplified and consistent. Verify that these numeric types meet all range requirements.Would you like a script to confirm any potential overflow or mismatch with upstream code that expects different gas field types?
83-88:Details
✅ Verification successful
Validate new
Fromimplementation regarding potential overflow.The
.0extraction suggests an internal newtype. Ensurevalue.receipt.gas.l1_gas.0,value.receipt.da_gas.l1_data_gas.0, andvalue.receipt.gas.l2_gas.0fit withinu64without truncation.
🏁 Script executed:
#!/bin/bash # Description: Check blockifier's definitions of gas fields to confirm they are within u64 range. # Searching for the type definitions of l1_gas, l2_gas, etc., in blockifier rg -A 10 "pub struct GasCost" . rg -A 10 "l1_gas" . rg -A 10 "l2_gas" .Length of output: 73184
Confirmed: Gas fields conversion is safe.
Our investigation indicates that the inner types for
l1_gas,l1_data_gas, andl2_gasare newtypes wrapping values that are already represented asu64(as evidenced by their usage across multiple tests and in the conversion logic incommon/utils.rs). There is no indication of potential overflow or truncation when extracting the inner values using.0.crates/starknet-devnet-server/src/api/json_rpc/spec_reader/spec_modifier.rs (7)
14-14: Renamed field clarifies usage.
replace_propertyis more descriptive thanreplace. This should improve readability.
29-31:replace_modefield addition is straightforward.Using
#[serde(default)]ensures a safe fallback and avoids potential parsing breakage.
63-79: Doc comments explain usage effectively.The expanded function-level documentation clarifies the behavior of
add_property, especially with thedo_replaceparameter.
83-101: Conditional insertion logic is sound.The logic correctly parses the value and either replaces the existing property or always inserts, depending on
do_replace. This approach appears robust for JSON adjustments.
130-130: Iterating overreplace_propertyarray.This change ensures the loop uses the renamed field. No issues noted.
137-142: Properly passingreplace_modeintoadd_property.This matches the new parameter signature. The usage is consistent with the updated function logic.
158-163: Improved error logging with fallback file dump.Writing the failed spec to
failed_spec.jsonaids debugging. This is a solid approach for diagnosing malformed JSON.crates/starknet-devnet-types/src/rpc/block.rs (5)
19-19: Extension ofBlockIdwithSerializeis beneficial.Enabling serialization can help in logging or API responses. This looks safe.
98-98: Addingl2_gas_pricefield aligns with existing structure.The new resource price field is consistent with the existing pattern of
ResourcePrice. Ensure it’s populated correctly in all relevant places.
124-136:ReorgDatastruct is a clear reorg representation.The fields and
deny_unknown_fieldsattribute ensure well-defined input. This seems appropriate for reorg tracking.
138-176:SubscriptionBlockIdenum elegantly handles block ID forms.The additional
Deserializelogic preventspendingusage and ensures clarity for watchers or subscriptions.
178-224: Tests robustly cover valid/invalid subscription block IDs.These test cases thoroughly validate edge scenarios, preventing regressions.
crates/starknet-devnet-types/src/rpc/contract_class.rs (13)
6-8: Validate necessity ofRunnableCompiledClass.
The imports indicate direct references toRunnableCompiledClassand supporting structures fromblockifier::execution::contract_class. Ensure that each imported symbol is indeed used; otherwise, remove it to avoid confusion.
15-16: Confirm usage of newly imported structures.
SierraVersion,EntryPointType,EntryPointOffset, andEntryPointV0are vital for Cairo 1 and Cairo 0 contract class manipulations. Verify their usage is consistent with the rest of the code.
27-27: Check utility coverage.
compile_sierra_contractis referenced below; ensure comprehensive tests are in place to validate its correctness, especially for edge cases involving incomplete contract definitions.
67-69: Good compliance with the new Cairo 1 flow.
ImplementingFrom<SierraContractClass>ensures a straightforward conversion path toContractClass::Cairo1. This looks clean and consistent.
99-99: Check multi-version alignment.
The newimpl TryFrom<ContractClass> for starknet_api::contract_class::ContractClasshandles both Cairo0 and Cairo1. Confirm that the usage ofstarknet_apialigns with the newly introduced logic for versioned classes.
112-115: Compile Sierra contract checks.
Compiling Sierra contracts here depends oncompile_sierra_contract(&sierra_contract_class). Confirm that partial compilation failures are bubbled up meaningfully.
121-121: Use consistent struct conversion approach.
impl TryFrom<ContractClass> for ClassInfounifies Cairo0 and Cairo1 paths. Verify all usage sites handle the returnedClassInfoproperly, especially for any extended fields.
131-131: Follow up on V0 structure usage.
CreatingContractClass::V0(...)is no longer typical for new Cairo 1 classes. Confirm that all references to V0 are restricted only to legitimate legacy flows.
142-142: Deployment alignment with new approach.
Migrating to Cairo 1 might invalidate some usage ofClassInfo::new(...)for older flows. Double-check that logic for common deployment paths.
156-156: Carry consistent state for integrated calls.
Since the conversion calls.try_into()withContractClass::Cairo1(...), confirm that each step references the same underlying object for hashing and any further transformations.
215-227: ValidateTryFrom<ContractClass>flattening logic.
This block seamlessly merges Cairo0 and Cairo1 paths intoRunnableCompiledClass. Confirm that the code handles usage for advanced features (e.g., constructor checks).
326-332: Ensure cohesive handling ofSierraVersion.
Theconvert_codegen_to_blockifier_compiled_classlogic references the version from codegen. Double-check that the resultingRunnableCompiledClassconsistently matches the version’s capabilities (e.g., no uninitialized fields).
337-343: Sustain clarity onClassHashusage.
Deserializing older classes and converting them toRunnableCompiledClass::V0can be tricky. Validate that the re-hashing logic or mismatch with the new compile route does not produce unintended discrepancies.crates/starknet-devnet-types/src/rpc/transactions.rs (19)
4-4: Verify version constraints.
use blockifier::transaction::account_transaction::ExecutionFlags;may presuppose certain minimum blockifier versions. Ensure yourCargo.tomlmatches.
16-19: Align resource bounds usage with GasVectorComputationMode.
New imports fromstarknet_api::transaction::fieldssuggest deeper bridging between resource bounds and transaction fields. Confirm the newly introduced logic thoroughly accounts for edge cases (e.g., L2-only, L1-only).
22-23: Confirm transitions to new transaction finality states.
TransactionExecutionStatusandTransactionFinalityStatuswere introduced. Validate that logic in the Devnet environment correctly maps partial states to final confirmations.
39-40: Check for performance overhead in resource retrieval.
use super::transaction_receipt::{ExecutionResources, FeeInUnits, TransactionReceipt};ties into cost measurement. Ensure no repeated computations for large blocks of transactions.
106-115: Implement robust fallback forgas_vector_computation_mode.
Lines 106-115 show logic returningGasVectorComputationMode::NoL2Gasif the transaction is not V3. Confirm that non-V3 transactions properly handle resource bounds or skip them as intended.
193-201: Confirm new transaction status fields.
TransactionStatus { finality_status, failure_reason, execution_status }is expanded. Make sure logs or error flows are consistent with these new statuses.
229-234: Maintain consistent error messages for fallback.
In theimpl InvokeTransaction, lines 229-234 unify the path forV1vs.V3. IfV2or any older versions were used before, confirm they’re fully deprecated.
386-387: Revise or confirm cost computations.
convert_resource_bounds_from_starknet_rs_to_starknet_apimay fail if themax_price_per_unitis unexpectedly large. Double-check integer bounds for very large values.
515-526: Ensure cohesiveis_max_fee_valid()checks.
The introduced logic ensures a transaction is invalid if certain bounds are zero. Confirm that zeroing out only some resource bounds is never inadvertently accepted.
568-569: Ensure removed versions are truly gone.
BroadcastedDeclareTransaction::V2(_) => trueis flagged as deprecated. Check that no code depends on these older versions in production.
624-629: Check compilation for V3 classes.
Ifcompute_sierra_class_hashfails or returns unexpected results, ensure that the transaction (line 627-629) is gracefully handled.
681-685: Double-checkbroadcasted_deploy_account_transactionlogic.
Line 684 callsv3.common.are_gas_bounds_valid(). Confirm that partial L1 or L2 bounds do not incorrectly pass.
756-770: Verify contract address correctness.
Line 765 calculates the contract address for a version 3 deploy account. If any new salting approach is introduced, ensure it’s in sync with the rest of the system.
788-789: Check for overshadowing old transaction logic.
Older V2 or V1 logic for invoke transactions is removed in favor of V3 (line 789 references...are_gas_bounds_valid()). Confirm no user needs backward compatibility.
885-889: Deprecate or remove v1 deploy account usage.
A check is done for version "0x1". Ensure no unmaintained code remains that references older flows.
1011-1012: Optional validation forvalidate_invocation.
Make sure that skipping of validation (e.g.,validate_invocation: None) is fully intentional. Otherwise, you might incorrectly assume a transaction was validated.
1024-1027: Uniform approach for declare transaction traces.
Similar to invoke traces, confirm thatvalidate_invocationorfee_transfer_invocationare properly handled.
1067-1068: Confirm usage ofVersionedConstantsfor function calls.
When convertingcall_infointoFunctionInvocation, you rely onversioned_constants. Double-check that no mismatch arises for older transactions.
1136-1143: Ensure consistent transaction statuses in public APIs.
L1HandlerTransactionStatusand other statuses introduced could mismatch if older code expects different finalities.crates/starknet-devnet/Cargo.toml (1)
42-42: Added reqwest dependency for HTTP client functionalityAdding the reqwest HTTP client library is appropriate for making external API requests. This aligns with the Starknet 0.13.4 update which may require additional HTTP communication capabilities.
crates/starknet-devnet-types/src/rpc/messaging.rs (1)
14-14: Enhanced L1-L2 message tracking with transaction hashAdding the
l1_transaction_hashfield toMessageToL2improves the cross-layer messaging system by tracking the originating transaction hash from L1. This is a good addition that enables better traceability between L1 and L2 transactions in the StarkNet ecosystem..circleci/config.yml (2)
107-107: Updated Rust toolchain to 1.83.0 for Blockifier compatibilityUpgrading the Rust toolchain version from 1.76.0 to 1.83.0 is necessary for compatibility with the updated Blockifier dependency as mentioned in the PR objectives. This is a breaking change but required for the StarkNet 0.13.4 update.
145-145: Updated Docker image to use Rust 1.83.0Updating the Docker image to use Rust 1.83.0 is consistent with the toolchain update in the build step. This ensures that the same Rust version is used throughout the CI/CD pipeline.
crates/starknet-devnet-server/src/api/json_rpc/spec_reader/spec_schemas/integer_primitive.rs (1)
13-14: Added maximum field to IntegerPrimitive for value range constraintsAdding the
maximumfield to complement the existingminimumfield provides complete range validation capabilities for integer values. Theskip_serializing_ifattribute is correctly applied to maintain clean JSON output when the field is not used.tests/integration/common/errors.rs (1)
1-1: Display trait implementation enhances error handlingAdding the
fmt::Displayimplementation forRpcErroris a good practice for improved error reporting and logging. This implementation will allow RpcErrors to be more easily formatted as strings in error messages.Also applies to: 63-67
crates/starknet-devnet-server/src/api/http/endpoints/accounts.rs (1)
94-94:Details
✅ Verification successful
Default fee unit updated from WEI to FRI
Changing the default unit from
FeeUnit::WEItoFeeUnit::FRIaligns with Starknet's 0.13.4 update. This change is appropriate but could affect API consumers who rely on the previous default behavior.Verify that this change is consistent with other fee unit defaults in the codebase:
🏁 Script executed:
#!/bin/bash # Check for other occurrences of FeeUnit default values rg "unwrap_or\(FeeUnit::(WEI|FRI)" --type rustLength of output: 285
Default Fee Unit Change Consistent Across Endpoints
The update to usingFeeUnit::FRIas the default (instead ofWEI) inaccounts.rsis verified to be consistent with its usage inmint_token.rs, aligning with Starknet’s 0.13.4 update. This change is appropriate; however, please ensure that API consumers are informed about the updated default behavior.
- Confirmed in:
crates/starknet-devnet-server/src/api/http/endpoints/accounts.rscrates/starknet-devnet-server/src/api/http/endpoints/mint_token.rscrates/starknet-devnet-types/src/lib.rs (1)
13-13: Appropriate export of Sierra contract compilation utilitiesExposing the Sierra contract compilation utilities at the crate root level improves API usability for consumers who need to compile Sierra contracts to CASM contracts.
crates/starknet-devnet-server/Cargo.toml (1)
37-37:Details
✅ Verification successful
Moving rand from dev-dependencies to dependencies
The
randcrate has been promoted from a development dependency to a regular dependency, indicating it's now used in the main codebase rather than just in tests.Let's verify where
randis now being used in the main code:
🏁 Script executed:
#!/bin/bash # Find usages of rand in the main code (excluding tests) rg "use rand::" --type rust crates/starknet-devnet-server/src/ | grep -v "test"Length of output: 186
Rand Dependency Promotion Verified
The verification confirms thatrandis actively used in the main codebase (e.g., incrates/starknet-devnet-server/src/api/json_rpc/spec_reader/data_generator.rs), which validates moving it from dev-dependencies to regular dependencies.crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v2.rs (1)
2-2: Updated import path for Fee typeThe import path for
Feehas been updated fromstarknet_api::transaction::Feetostarknet_api::transaction::fields::Fee. This change is part of the API restructuring in Starknet 0.13.4 update, where types have been reorganized into more specific modules.crates/starknet-devnet-server/src/api/json_rpc/spec_reader/spec_schemas/mod.rs (3)
2-2: New import for Tuple schemaAdded import for the
Tupletype from the newtuple_schemamodule, which will be used for handling tuple types in JSON-RPC schemas.
21-21: Added new tuple_schema moduleNew module for handling tuple schemas in the JSON-RPC specification. This adds support for tuple data structures, enhancing the schema definition capabilities.
57-57: Added Tuple variant to Schema enumAdded a new
Tuple(Tuple)variant to theSchemaenum, allowing the system to represent and process tuple schemas in the JSON-RPC specification. This extends the type system to support more complex data structures.crates/starknet-devnet-core/Cargo.toml (1)
15-15: Updated blockifier dependency with transaction_serde featureThe blockifier dependency now includes the
transaction_serdefeature, which adds serialization/deserialization support for transactions. This change is necessary to support the updated transaction handling in Starknet 0.13.4.Also note that the
uscdependency has been removed from this file.crates/starknet-devnet-core/src/lib.rs (1)
20-20: Added CasmContractClass exportAdded a public export for
CasmContractClassfrom the Cairo language Starknet classes module. This makes the class directly available to users of this crate, simplifying the usage of compiled Starknet contracts.Note that the
raw_executionmodule has been removed (this removal is not shown in the diff).crates/starknet-devnet-server/src/server.rs (1)
60-60: WebSocket route properly added for JSON-RPC API 0.8 support.This addition successfully implements WebSocket connections at the
/wspath, enhancing the server to handle both HTTP and WebSocket JSON-RPC requests. This aligns with the PR objective to update to Starknet 0.13.4 and RPC 0.8.crates/starknet-devnet-server/src/api/json_rpc/spec_reader/spec_schemas/tuple_schema.rs (1)
1-20: Tuple schema implementation is well structured.The new
Tuplestruct correctly implements theAcceptortrait and follows the established pattern of other schema types. The structure withcommonandvariantsfields appropriately represents tuple schemas in the JSON-RPC specification.crates/starknet-devnet-server/src/api/http/endpoints/mint_token.rs (1)
38-44: Error handling refactored correctly.The error response has been improved by switching from
ApiError::ContractErrortoApiError::StarknetDevnetErrorand using more modern string interpolation. This change better represents the nature of the error.crates/starknet-devnet-server/src/api/json_rpc/spec_reader/spec_schemas/array_primitive.rs (1)
12-13: Added array size constraints enhance schema validation.The addition of
min_itemsandmax_itemsfields improves the array schema capabilities by allowing specification of size constraints. This is a good enhancement consistent with JSON Schema standards.crates/starknet-devnet-server/src/rpc_core/response.rs (1)
26-29: Enhanced error response creation with explicit ID handlingThe new
from_rpc_errormethod properly requires an explicit ID parameter, ensuring all error responses have a valid identifier. This is a better approach than the removedFrom<RpcError>implementation which would create responses withNoneIDs.crates/starknet-devnet-core/src/system_contract.rs (1)
4-5: Appropriate update to import from deprecated moduleGood update of the import path for
Cairo0Jsonto use thedeprecatedmodule, which aligns with the Starknet version upgrade. This accurately reflects the transition away from Cairo 0 as part of the move to Starknet 0.13.4.crates/starknet-devnet-server/src/api/mod.rs (1)
11-11:Details
✅ Verification successful
Good addition of WebSocket support through SocketCollection
The addition of the
socketsfield and its initialization in the constructor properly enables WebSocket functionality, which is a required feature in JSON-RPC API 0.8. The thread-safe implementation usingArc<Mutex<>>is appropriate for a shared resource.However, to verify this implementation will work correctly:
Also applies to: 20-20, 25-29
🏁 Script executed:
#!/bin/bash # Check for WebSocket endpoint handlers using the new sockets field rg -A 5 "sockets" --glob "*.rs" crates/starknet-devnet-server/src/Length of output: 10418
Verified: The WebSocket support via
SocketCollectionis properly implementedThe search results confirmed that the new
socketsfield is consistently used across the codebase in modules such assubscribe.rsand various JSON-RPC endpoints (includingwrite_endpoints.rs,mod.rs, andendpoints_ws.rs). The thread-safe initialization withArc<Mutex<>>and usage in handling WebSocket endpoints is sound and meets the requirements for JSON-RPC API 0.8.No further changes are required.
crates/starknet-devnet-types/src/rpc/gas_modification.rs (3)
12-13: LGTM! Clean addition of L2 gas price fieldsThe new
l2_gas_price_weiandl2_gas_price_frifields follow the same pattern as the existing gas price fields, maintaining consistency in the API design.
24-25: LGTM! Consistent struct field additionsThe L2 gas price fields are added to the
GasModificationstruct matching the pattern used inGasModificationRequest.
42-47: LGTM! Proper implementation of update logicThe update method is correctly extended to handle the new L2 gas price fields, following the same pattern as the existing fields.
crates/starknet-devnet-types/src/rpc/transactions/deploy_account_transaction_v3.rs (2)
3-3: LGTM! Updated import path for TipThe import has been updated to use the new location of
Tipin thefieldssubmodule, which is likely part of the API reorganization in Starknet 0.13.4.
60-62: LGTM! Added accessor method for resource boundsThe new getter method follows the same pattern as the existing
get_contract_addressmethod and provides access to the resource bounds, which might be needed for gas estimation or other calculations.crates/starknet-devnet-core/src/messaging/ethereum.rs (4)
10-10: LGTM! Added Hash256 importThe import of
Hash256fromstarknet_rs_core::typesis added to support the new transaction hash tracking feature.
305-305: LGTM! Added L1 transaction hash extractionThis change captures the Ethereum transaction hash and maps it to the Starknet-compatible
Hash256type, enabling cross-chain transaction tracing.
322-322: LGTM! Added L1 transaction hash to MessageToL2The L1 transaction hash is now included in the returned MessageToL2 struct, completing the cross-chain transaction tracking feature.
410-410: LGTM! Updated test caseThe test case has been properly updated to include the new
l1_transaction_hashfield with aNonevalue, as expected in the test scenario.crates/starknet-devnet-server/src/rpc_handler.rs (3)
4-6: LGTM! Added WebSocket importsThe new imports from axum are required to support WebSocket functionality, including connection handling and upgrade management.
39-40: Added WebSocket support to RpcHandler traitThe new method requires implementation by all RpcHandler implementers to support WebSocket connections. This is a good addition for real-time communication capabilities.
Make sure all implementers of the
RpcHandlertrait provide an implementation for this new method to avoid compilation errors.
60-70: LGTM! Well-implemented WebSocket upgrade handlerThe function properly handles WebSocket upgrades, logs connection events and errors, and delegates to the handler's
on_websocketmethod.crates/starknet-devnet-core/src/contract_class_choice.rs (2)
5-6: Import path updated to use the deprecated module for Cairo0JsonThe import path for
Cairo0Jsonhas been updated to use the deprecated module, which aligns with the Starknet 0.13.4 update. This change follows the proper migration pattern for deprecated components.
24-24: Whitespace added for better code readabilityAdded a blank line after constructing the
contract_classvariable for better code organization.crates/starknet-devnet-core/src/starknet/events.rs (8)
1-1: Added import for BlockStatusAdded import for
BlockStatusfromstarknet_api::blockto support proper handling of pending blocks.
65-69: Improved handling of pending blocksNow properly handling pending blocks by setting both
block_hashandblock_numbertoNonewhen the block status isPending. This change correctly represents the state of pending blocks that don't have finalized hash or number yet.
73-74: Updated variable assignments for blocksUpdated to use the conditionally defined variables for block hash and number, maintaining consistency with the new pending block handling logic.
95-95: Changed visibility of check_if_filter_applies_for_eventChanged visibility from private to public, making the function accessible to other modules. Ensure this is intentional and that the function's behavior remains consistent when used externally.
This function was made public, but there is no indication in the current context as to why. Please verify that this change is intentional and needed by other components.
134-134: Updated import to include BlockTagAdded
BlockTagto the import, which is now being used in the tests below.
144-144: Updated import for transaction dummyChanged from
dummy_declare_transaction_v1todummy_declare_transaction_v3, aligning with the RPC 0.8 transaction version updates.
401-401: Updated to use version 3 of declare transactionChanged from
dummy_declare_transaction_v1()todummy_declare_transaction_v3()in the test setup, maintaining consistency with the RPC 0.8 transaction versioning.
414-417: Updated test assertions using BlockTagModified assertion to explicitly use
BlockId::Tag(BlockTag::Latest)instead of an implicit check, improving test clarity and aligning with the new API usage patterns.crates/starknet-devnet-types/src/rpc/contract_class/deprecated/mod.rs (2)
4-4: Updated import path for Cairo0JsonUpdated import path to use the new deprecated module structure, which is consistent with the architecture changes in Starknet 0.13.4.
73-73: Changed TryFrom implementation target typeModified the implementation of
TryFromforCairo0ContractClassto targetstarknet_api::deprecated_contract_class::ContractClassinstead ofblockifier::execution::contract_class::ContractClassV0. This change reflects the architectural shift from blockifier to the starknet API, aligning with the update to Starknet 0.13.4.crates/starknet-devnet-types/src/rpc/transactions/broadcasted_invoke_transaction_v1.rs (4)
2-2: Updated import path for FeeUpdated import path from
starknet_api::transaction::Feetostarknet_api::transaction::fields::Fee, reflecting the reorganization in the starknet_api crate.
42-42: Updated import path for Fee in testsUpdated the same import path in the test module, maintaining consistency with the main code changes.
87-88: Switched to starknet API for transaction creationChanged from
create_blockifier_invoke_transactiontocreate_sn_api_invoke, reflecting the transition from blockifier to the starknet API for transaction handling. This aligns with the Starknet 0.13.4 update objectives.
90-90: Updated assertion for transaction hash verificationModified assertion to use
executable_tx.tx_hash()instead ofblockifier_transaction.tx_hash.0, maintaining consistency with the new starknet API based transaction implementation.crates/starknet-devnet-core/src/starknet/get_class_impls.rs (2)
2-5: Import changes look good.The imports have been updated to bring in necessary types for the new functionality, including
CasmContractClass,BlockId,BlockTag, andcompile_sierra_contract. These imports appropriately support the new function added below.
42-42: Good documentation addition.The added comment clarifies the behavior of the function regarding the different returns for Cairo0 vs Cairo1 contracts, which improves code clarity.
crates/starknet-devnet-core/src/starknet/state_update.rs (2)
20-24: Import paths updated correctly.The import for
Feehas been updated to the new location instarknet_api::transaction::fields, andcompile_sierra_contracthas been added to support the simplified class hash calculation.
39-40: Good simplification of compiled class hash calculation.The code now directly uses
compile_sierra_contractto obtain the compiled class hash, making the implementation cleaner and more maintainable than the previous approach.tests/integration/common/constants.rs (2)
17-17: Added WebSocket path constant.The new
WS_PATHconstant supports WebSocket functionality, which aligns with the PR's objective to update to RPC 0.8. This constant will be used for WebSocket endpoint configuration.
86-89: URL endpoints updated to v0_8.The endpoints for integration and mainnet have been appropriately updated from v0_7 to v0_8, which is consistent with the PR's goal of updating to RPC 0.8.
crates/starknet-devnet-types/src/rpc/transactions/declare_transaction_v3.rs (3)
3-3: Import path updated correctly.The import for
Tiphas been updated to the new location instarknet_api::transaction::fields, consistent with other similar changes in the PR.
26-26: Appropriate visibility change for sender_address.Changing the visibility of
sender_addresstopub(crate)provides the necessary access within the crate while maintaining proper encapsulation from external code.
54-56: Added accessor method for resource_bounds.This method follows a consistent pattern seen in other transaction type implementations, providing controlled access to the resource bounds. The implementation is simple and effective.
crates/starknet-devnet-core/src/starknet/starknet_config.rs (4)
14-16: Updated imports to support Layer 1 and Layer 2 gas prices.The imports have been correctly updated to use the new gas price constants that distinguish between L1 and L2 gas prices, which aligns with the Starknet 0.13.4 update.
113-114: New fields for Layer 2 gas prices added to StarknetConfig.These new fields properly support the Layer 2 gas pricing introduced in Starknet 0.13.4.
133-140: Added helper method to determine block generation strategy.This is a helpful utility method that clearly indicates whether the configuration uses a pending block based on the block generation strategy.
158-164: Updated default implementation for StarknetConfig.The default implementation correctly initializes the new L2 gas price fields using the constants defined in the updated constants file.
crates/starknet-devnet-core/src/state/state_diff.rs (9)
53-59: Updated state diff to access properties through state_maps.The code now correctly accesses compiled class hashes through the new
state_mapsfield, which is part of the structural changes in Starknet 0.13.4.
61-70: Updated address_to_class_hash mapping retrieval.This section properly adapts to the new state_maps structure while maintaining the previous logic for mapping addresses to class hashes.
72-82: Updated class hash iteration and replacement logic.The loop now correctly iterates over the class hashes from the new state_maps structure while preserving the logic for detecting and handling class replacements.
84-93: Updated address_to_nonce mapping retrieval.This section properly adapts to the new state_maps structure for accessing nonces.
96-99: Updated storage updates iteration.Storage updates are now correctly retrieved from the state_maps structure.
185-185: Updated import for Fee type.The import has been updated to reflect the reorganization of the Fee type into the fields module in the new API version.
188-189: Simplified class hash handling.The code now uses a direct reference to the dummy compiled class hash instead of an explicit conversion, making the code cleaner.
224-224: Simplified casm_hash assignment.Using the constant directly improves code readability.
227-227: Improved error condition check.The modified error check is more explicit about the expected failure condition.
crates/starknet-devnet/src/main.rs (4)
10-10: Updated imports to support JSON-RPC and improved error logging.The imports have been updated to include JSON serialization, dump utilities, and proper error logging, which are needed for the refactored block interval creation function.
Also applies to: 14-14, 41-41
334-336: Refactored block interval creation approach.Block creation now happens via HTTP requests to the running instance rather than direct API access. This decoupling is a good architectural improvement.
359-363: Updated create_block_interval method signature.The method no longer takes an Api parameter and instead uses a devnet_address string, which aligns with the HTTP-based approach.
373-387: Reimplemented block creation with HTTP requests.The block creation mechanism has been refactored to use HTTP requests through the reqwest client, which properly decouples the block creation logic from the API object. The change includes good error handling and logging.
crates/starknet-devnet-core/src/constants.rs (2)
96-98: Updated gas price constants to support Layer 1 and Layer 2.The gas price constants have been properly divided into L1 and L2 specific constants, which aligns with the changes to the StarknetConfig struct and supports the layer-specific gas pricing in Starknet 0.13.4.
115-116: Added new error constant for entrypoint not found.This constant improves error handling by providing a standard encoded representation of the "ENTRYPOINT_NOT_FOUND" error message.
crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v3.rs (4)
5-5: Import usage looks consistent.
No issues identified; this aligns well with usage in the rest of the file.
7-7: New import for CompiledClassHash.
This is appropriate for handling class hash computations or references.
22-24: Implementation of the From trait.
The conversion toSelf::V3(Box::new(value))is straightforward and clean. Consider ensuring that any usage ofBroadcastedDeclareTransactionV3is tested.
28-29: Removed test coverage note.
If the test is no longer relevant, that is fine. However, confirm there is equivalent coverage elsewhere to avoid regressions.crates/starknet-devnet-core/src/messaging/mod.rs (6)
35-36: Introduction of H256 and updated imports.
This switch to a more explicit hash type is a positive step for type safety.
58-58: Changed map key type from String to H256.
Great improvement in type correctness for tracking hashes.
61-62: New mapping field l1_to_l2_tx_hashes.
Introducing this field provides clear tracking of L1→L2 transactions. Ensure corresponding usage is properly tested.
140-140: Switched to block_header_without_hash.
This appears to align with new data structures. Verify it correctly retrieves the intended block number.
144-144: Converted message hash to H256.
This promotes consistency with the new hash type usage throughout the messaging flow.
190-191: Consistent usage of H256 for message hashes.
Maintains type uniformity, reducing potential collisions or format discrepancies.crates/starknet-devnet-types/src/rpc/contract_class/deprecated/json_contract_class.rs (5)
8-8: Refined import for EntryPointType.
Adopting the non-deprecated path looks aligned with current API usage.
9-9: Added import for EntryPointV0.
This reflects the newer API for deprecated contract classes; no concerns.
97-97: Switch to EntryPointV0 in entry_points_by_type.
A clear move toward updated contract class types.
236-236: Implemented TryFrom for ContractClass.
The direct conversion is concise. Confirm coverage so that no functionality is lost when converting legacy artifacts.
257-257: Updated reference to Cairo0Json in tests.
Keeps the file references consistent with the module’s deprecated structure.crates/starknet-devnet-core/src/starknet/add_l1_handler_transaction.rs (8)
2-2: Import usage is valid.
The added import fromethers::types::H256is needed for mapping L1 to L2 transaction hashes; no issues found.
15-17: Ensure all call-sites implement the new transaction creation.
The switch tocreate_sn_api_transactionis a clean improvement. Double-check that every L1 handler creation is updated to use this new method.
20-22: Execution flow looks correct.
Invoking the new execution path withblockifier::transaction::transaction_execution::Transaction::L1Handleris consistent with the intended refactor.
63-64: Exposure of new constants.
AddingSTRK_ERC20_CONTRACT_ADDRESSenhances coverage for the new token scenario. No issues noted.
135-158: Robust error matching in test.
The nested matching onContractExecutionErroris thorough. The finalpanic!is acceptable for a test scenario.
225-227: Refactor for clarity.
Extractingdummy_contractand converting intosn_api_classis logical for test setup. Code is self-explanatory.
232-235: Consistency with the L1 handler entry point check.
Minor changes to the chain of method calls to retrieve the field fromentry_points_by_type. This aligns with the new approach.
269-270: Revising block context.
Switching from zero tononzero!(1u128)for the block context fields helps avoid zero-based edge cases. Good improvement.crates/starknet-devnet-types/src/rpc/transactions/broadcasted_invoke_transaction_v3.rs (1)
22-45: Efficient construction of InvokeTransaction.
UsingArcto wrap calldata is beneficial for large arrays, and the flow for populatingInvokeTransactionV3fields is clear. Overall, this refactor away from direct hash calculation is well-structured.crates/starknet-devnet-core/src/starknet/defaulter.rs (4)
3-3: Adoption of RunnableCompiledClass import
The addition ofRunnableCompiledClassaligns with the new approach to contract class handling, replacing the previousContractClassusage. This looks consistent with the rest of the file’s changes.
143-145: Renamed function returning RunnableCompiledClass
Replacing the oldget_compiled_contract_classwithget_compiled_classthat returns aRunnableCompiledClassis coherent with the shift to the new type. Ensure that all call sites have been updated accordingly to prevent mismatch errors.
217-217: Private method signature update
The privateget_compiled_classmirrors the public method’s change, improving internal consistency. No issues found with the updated return type.
230-230: Error mapping inline conversion
The error mapping from JSON to the new compiled class structure looks correct. The call toconvert_codegen_to_blockifier_compiled_classfollowed by an immediatemap_errensures robust error propagation.crates/starknet-devnet-types/src/rpc/transactions/broadcasted_declare_transaction_v2.rs (4)
3-3: Refined import path for Fee
Switching tostarknet_api::transaction::fields::Feesuggests an upstream reorganization in thestarknet_apicrate. This import change is valid as long as the rest of the code now references the new location.
48-48: Consistent Fee import in tests
Mirroring the import change forFeein the test module maintains consistency. This avoids potential compilation errors or mismatched references.
102-102: API transition for declare transactions
Replacing.create_blockifier_declare(…)with.create_sn_api_declare(…)aligns with the new “sn_api” approach to declarations. Verify that any additional parameters or changes in returned types have been accounted for in the calling logic.
111-111: Pointer dereference for tx_hash
Using*blockifier_declare_transaction.tx_hashinstead ofblockifier_declare_transaction.tx_hash().0reflects a changed accessor pattern. Confirm that.tx_hashis a valid field and not impacted by other code references still expecting a method call.crates/starknet-devnet-core/src/blocks/mod.rs (33)
4-6: Expanded imports for block data
AddingBlockHeader,BlockHeaderWithoutHash,BlockNumber,BlockStatus, andBlockTimestampsuggests deeper usage of internal block fields. This is consistent with the changes to store more block header fields separately.
73-74: Updating parent hash
Assigningblock.header.block_header_without_hash.parent_hash = starknet_api::block::BlockHash(last_block_hash)is a correct approach to link the current block to its predecessor by setting the parent hash. No issues found.
129-130: Extract pending block number early
Storinglet pending_block_number = self.pending_block.block_number();for further checks is a clear approach. The subsequent blank line is likely just spacing; no concerns.
149-162: Utility for checking block number range
The newis_block_number_in_rangefunction makes the filtering logic concise. Ensure correct handling of edge cases (e.g., when “from” > “to”) is validated in calling code.
164-164: Initialize flag for pending block insertion
Declaringinsert_pending_block_in_final_result = trueupfront is straightforward. No immediate issues detected.
169-177: Filtering blocks by range
This filtering pipeline checks the block number range for each block and updatesinsert_pending_block_in_final_resultif the block number matchespending_block_number. The logic appears correct, preventing double inclusion of the pending block.
179-188: Appending pending block conditionally
Appending the pending block to the final list only if it’s in range and wasn’t seen earlier is sensible. This ensures correct behavior for queries that include pending.
212-217: Reading price_in_fri
Extractingprice_in_frifrom the embeddedBlockHeaderWithoutHashfields follows the newResourcePricestructure. Looks correct.
227-234: Reading price_in_fri for l1_data_gas_price
Same pattern repeated forl1_data_gas_price. The approach ensures consistent capture of resource pricing.
243-258: Reading l2_gas_price
Again, consistent usage of theResourcePricestructure forl2_gas_price. No correctness issues found.
274-288: l1_gas_price in the TypesBlockHeader
Extracting the L1 gas price for the block header matches the approach inTypesPendingBlockHeader. Maintaining uniform fields across both pending and accepted block headers is good for clarity.
290-304: l1_data_gas_price in the TypesBlockHeader
Matches the pattern from the previous aggregator. No additional concerns.
305-321: l2_gas_price in the TypesBlockHeader
Completes the set of updated resource prices. This final addition is consistent with the prior changes.
343-345: Accessor for parent_hash
Accessingself.header.block_header_without_hash.parent_hash.0centralizes the block’s parent hash retrieval. No issues identified.
347-347: Sequencer address accessor
self.header.block_header_without_hash.sequencer.0.into()indicates the internal data type is being mapped toContractAddress. Straightforward conversion with minimal overhead.
352-353: Timestamp retrieval
self.header.block_header_without_hash.timestampmaintains a more direct read of the block’s timestamp field. No issues.
356-357: State root retrieval
Directly returningself.header.block_header_without_hash.state_root.0aligns with the block header’s new structure. Looks good.
364-365: Block number retrieval
self.header.block_header_without_hash.block_numberis straightforward. Ensure consistency with the rest of the code referencing this same source.
370-373: Constructing default pending block
InitializingBlockHeaderWithoutHashwithl1_da_mode: L1DataAvailabilityMode::Blobensures consistent default for pending. The usage of..Default::default()is clear.
381-387: Function to create an accepted block
create_empty_accepted()is a convenient helper for building an accepted-on-L2 block with no transactions. This covers the new block lifecycle scenario.
390-391: Setting block number
self.header.block_header_without_hash.block_number = BlockNumber(block_number)provides a direct setter. Straightforward approach, no issues.
394-395: Setting timestamp
self.header.block_header_without_hash.timestamp = timestamp;consistently modifies the block’s timestamp in place. No concerns.
402-405: In-hash calculation for block number/state root
Placingfelt!(self.header.block_header_without_hash.block_number.0)andself.header.block_header_without_hash.state_root.0in the array for hashing is consistent with the new structure. No immediate issues.
419-419: In-hash calculation for parent hash
Includingself.header.block_header_without_hash.parent_hash.0in the block hash generation ensures correct chain linkage.
427-429: Test module import expansions
Importing expanded block definitions (BlockHash, BlockHeader, BlockHeaderWithoutHash, BlockNumber, BlockStatus) is consistent with the tested changes.
443-444: Initialize block number in tests
block_to_insert.header.block_header_without_hash.block_number = BlockNumber(block_number);ensures each test block is labeled. Straightforward.
449-450: Advance the pending block number
blocks.pending_block.header.block_header_without_hash.block_number = BlockNumber(block_number).unchecked_next();in test context is safe to set a future block.
452-458: Test: retrieving all blocks
Gathering a Vec of block numbers with no filter ensures that blocks + the pending block appear. The final assertion checks the expected ascending sequence. Looks correct.
460-467: Test: filtering from block 7 to the end
get_blocks(Some(BlockId::Number(7)), None)yields blocks 7 through 10, plus the next pending. The final assertion confirms the result set. Nicely tested.
468-475: Test: filtering block 7 to the latest
get_blocks(Some(BlockId::Number(7)), Some(BlockId::Tag(BlockTag::Latest)))excludes the pending block if the latest block is 10. Confirmed by the final assertion.
837-843: Test: default parent hash for first block
These assertions confirm that block #0’s parent hash isBlockHash::default(), ensuring correct ancestry for the genesis block.
847-853: Test: linking block 1 to block 0
Ensures that block #1’s parent hash matches block #0’s hash. Validates the chain linkage logic introduced above.
856-862: Test: verifying block #1 and block #2 differ
Confirming that block #1’s parent hash is not equal to block #2’s parent hash helps detect accidental collisions or incorrect linking.crates/starknet-devnet-server/src/api/json_rpc/spec_reader/data_generator.rs (4)
14-14: The import ofTupleis appropriate to support the newly added tuple schema handling.
38-40: New trait method bolsters extensibility.
This addition ofdo_for_tuplecomplements the schema-based approach by allowing explicit handling of tuple schemas. Ensure that any other code sections that work with tuple schemas consistently invoke or override this method if needed.
57-57: Simplifiedimpl Visitor for RandDataGenerator<'_>is a good cleanup.
Removing the explicit lifetime parameter aligns well with Rust's advanced lifetime inference, making the code more concise without sacrificing clarity.
99-100:Details
✅ Verification successful
Potential panic if
minimumexceedsmaximum.
When generating numbers usinggen_range, the range must not be empty to avoid a runtime panic. Ifelement.minimumis greater thanelement.maximum, the method may panic.Please verify that no code path assigns conflicting values to
element.minimumandelement.maximum. For thorough checking, run the script below to search for all instantiations or mutations ofelement.minimumandelement.maximum:If any suspicious assignments exist (e.g., setting
minimum>maximum), consider adding checks to prevent or handle such cases.
🏁 Script executed:
#!/bin/bash # Searching for any code that sets or modifies minimum/maximum in the schema definitions or usage. # We'll check for direct assignments or struct initializations referencing `.minimum` or `.maximum`. rg -A 3 -B 3 "(minimum|maximum)"Length of output: 27258
Potential runtime panic: Ensure valid range for random generator
After reviewing the repository, no code paths were found that directly assign conflicting values to
element.minimumandelement.maximum. The schema definitions and test data (e.g., in the JSON specs and YAML configuration) consistently provide values whereminimumis less than or equal tomaximum. Therefore, under the current setup, the use oflet num = rand::thread_rng() .gen_range(element.minimum.unwrap_or_default()..element.maximum.unwrap_or(i32::MAX));seems safe.
That said, to guard against any potential misconfigurations (especially if these values come from user-supplied input or external sources), consider adding an explicit validation step (or debug assertion) to check that
element.minimum <= element.maximumbefore invokinggen_range. This would provide a clearer error message rather than risking a runtime panic.crates/starknet-devnet/src/cli.rs (7)
10-13: New constants for enhanced gas price granularity.
AddingDEVNET_DEFAULT_L1_DATA_GAS_PRICE,DEVNET_DEFAULT_L1_GAS_PRICE, andDEVNET_DEFAULT_L2_GAS_PRICEclarifies the distinction between L1 vs. L2 gas pricing structures.
120-121: Clearer help text for L1 gas price in Wei.
Specifying “L1 gas unit” reduces ambiguity about which context these gas prices apply to.
128-129: Mirroring L1 Wei price logic for L1 Fri price.
Consistent naming and default values help maintain code clarity and uniform behavior.
137-138: Set default L1 data gas price in Wei.
Providing a separate data gas price parameter is a beneficial separation of concerns for data usage on L1.
145-146: Set default L1 data gas price in Fri.
This mirrors the Wei-based data gas price default, maintaining consistency across resource cost parameters.
149-163: New L2 gas price parameters are well introduced.
Definingl2_gas_price_weiandl2_gas_price_friwith their own defaults fosters clear separation between L1 and L2 pricing strategies.
263-264: Correct passing of newly introduced L2 gas prices toStarknetConfig.
This ensures that downstream logic receives the correct configured values for L2 resource pricing.crates/starknet-devnet-core/src/state/state_readers.rs (4)
3-3: ImportingRunnableCompiledClasssupports the shift fromContractClass.
This aligns with the updated blockifier usage for contract execution.
20-20: Mappingclass_hash_to_classtoRunnableCompiledClass.
Switching fromContractClassensures the state is ready for direct execution-compatible classes.
113-114: Updatingset_contract_classto acceptRunnableCompiledClass.
Storing execution-ready classes inDictStatehelps unify compilation outputs in one place. Good step toward a more robust devnet state.
51-55:Details
✅ Verification successful
Replacing
get_compiled_contract_classwithget_compiled_classforRunnableCompiledClass.
This is consistent with the updated blockifier interface. Verify that all references to the old function name are removed or updated.If any references show up, please update or remove them accordingly.
🏁 Script executed:
#!/bin/bash # Ensure no stale references to `get_compiled_contract_class` remain in the codebase. rg "get_compiled_contract_class"Length of output: 32
Verified: All references to the old function name have been removed.
The code incrates/starknet-devnet-core/src/state/state_readers.rsnow consistently usesget_compiled_classforRunnableCompiledClassper the updated blockifier interface, and no stale references toget_compiled_contract_classwere found in the repository.crates/starknet-devnet-server/src/api/json_rpc/endpoints.rs (9)
1-1: Unified import for error types.
CombiningContractExecutionError,Error, andStateErrorhelps centralize error handling logic.
16-18: Extended API models for new RPC features.
The additionsGetStorageProofInput,L1TransactionHashInput, andSyncingOutputsupport advanced Devnet RPC functionality.
27-27: Appropriate doc comment for JSON-RPC endpoint definitions.
This top-level documentation is beneficial for reference and code readability.
140-148:get_storage_proofreturns a controlled “not supported” error.
This explicit early return clarifies to integrators that Devnet doesn’t implement this RPC route. Good way to handle unimplemented features.
164-175: Refinedget_transaction_status_by_hashapproach.
Returning a directTransactionStatusByHashobject aligns with consistent JSON-RPC patterns. The fallback toTransactionNotFoundis well-defined.
313-321: Detailed handling ofEntrypointNotFoundandContractExecutionError.
Differentiating these error cases clarifies the cause of contract call failures, improving debugging and operators’ insight.
339-343: ExpandedContractExecutionErrorInSimulationhandling forestimate_fee.
This approach highlights partial transaction failures. It properly raisesTransactionExecutionErrorwith the failing index.
462-474: Consistent simulation error handling insimulate_transactions.
By similarly convertingContractExecutionErrorInSimulationintoTransactionExecutionError, the code remains consistent withestimate_fee.
500-510:get_messages_statusappropriately manages message statuses.
Introducing message-level checks for a given L1 transaction improves transparency for cross-layer transaction flows.crates/starknet-devnet-core/src/transactions.rs (4)
78-80: Better handling of revert reason.
UsingErrorStack::default().into()as a fallback is cleaner than a hardcoded string, ensuring a more consistent and descriptive error flow for reverted transactions.
226-229: Lightweight accessor addition.
Theget_block_numbermethod is straightforward. Just confirm that updates toblock_numberremain consistent if the transaction is reassigned to a different block or if chain reorganization logic evolves.
230-236: Clear transaction status retrieval.
The newget_statusmethod providing finality, failure reason, and execution status is beneficial for logging and debugging. No issues spotted.
170-170:Details
✅ Verification successful
Confirm fee correctness.
Replacing fee usage withFeeAmount { amount: self.execution_info.receipt.fee }looks fine, but verify that all transaction types setreceipt.feeproperly, especially if there are new or legacy variants with different fee calculation logic.
🏁 Script executed:
#!/bin/bash # Search for references to `receipt.fee` usage to confirm consistent fee assignment rg -A 5 "receipt\.fee"Length of output: 753
Fee consistency verified.
The search confirms that the fee is correctly set usingFeeAmount { amount: self.execution_info.receipt.fee }across all referenced transaction types. In the matching cases—Transaction::L1Handler(converting toFeeInUnits::WEI) and the V3 variants for Declare, DeployAccount, and Invoke (converting toFeeInUnits::FRI)—receipt.feeis used consistently. There is no evidence from the scan of any legacy or alternative transaction variants that would require different fee calculations.crates/starknet-devnet-types/src/rpc/contract_class/deprecated/rpc_contract_class.rs (3)
6-6: Move todeprecatedmodule looks consistent.
Renaming the import tocrate::contract_class::deprecated::Cairo0Jsonclarifies the intent for Cairo 0 code. Ensure any other references also follow suit.
100-100: Updated test import path.
Usingdeprecated::DeprecatedContractClassin tests is aligned with the new module structure. Confirm that all test utilities and mocks referencing the old path are also updated.
87-94:Details
❓ Verification inconclusive
Switch to
starknet_apicontract class.
Changing theTryFromtarget tostarknet_api::deprecated_contract_class::ContractClassmodernizes the conversion flow and removes blockifier-specific dependencies. Double-check downstream usage that relied on the old type.
🏁 Script executed:
#!/bin/bash # Look for references to ContractClassV0 or older blockifier-based conversions rg -A 5 "ContractClassV0"Length of output: 25
Action: Confirm switch to
starknet_apicontract class and verify downstream impactThe conversion now correctly targets
starknet_api::deprecated_contract_class::ContractClassand removes the blockifier-specific dependency. Our initial search for references to the old type (ContractClassV0) returned no output, which is promising. However, please manually verify that none of the downstream code still relies on the previous type.
- Verify that there are no remaining indirect dependencies on the old conversion flow.
- Confirm that all usages of
DeprecatedContractClassnow correctly operate with the updated conversion.crates/starknet-devnet-core/src/starknet/add_invoke_transaction.rs (17)
1-1: LeveragingExecutionFlags.
ImportingExecutionFlagssuggests a more granular approach to transaction execution control. No immediate concerns—just ensure the flags are consistently set to match your execution requirements.
28-29: Creatingsn_api_invoke.
Transition from a Blockifier-centric constructor tocreate_sn_api_invokesuggests adopting a more portable or standardized transaction creation flow. Check that metadata (e.g., chain ID, nonce) is consistently applied.
31-31: Double-check transaction hash format.
Storingsn_api_transaction.tx_hash.0directly astransaction_hashis correct if that field is guaranteed to be a rawFeltor similar. Confirm the type matches your Devnet hashing standards.
52-59: Refined transaction execution structure.
Wrapping your transaction inAccountTransaction::Invoke(...)withExecutionFlagsclarifies the execution context (fee charging, validation). Good approach. Make sure the blockifier is aware of these flags and yourstateis consistent with L2 updates.
62-62: Handling accepted transaction.
Forwarding theexecution_infointohandle_accepted_transactionneatly consolidates post-processing logic. Remain vigilant about error boundaries (e.g., partial reverts or new status codes).
205-205: Context: “fn invoke_transaction_v3_successful_execution_with_only_l1_gas()”.
Tests specifically targeting only L1 gas bounds are valuable. Consider adding negative tests where L2 gas is set incorrectly to guarantee your is_max_fee_valid() logic holds up.
208-209: Readinginitial_balance.
This ensures a baseline for verifying fee consumption. No issues found; verifying that the account has enough STRK balance is crucial for the test.
223-223: Validating transaction hashing.
Callingstarknet.add_invoke_transaction(invoke_transaction)ensures coverage for the L1-only scenario. No immediate concerns, but keep an eye on potential new transaction types.
226-226: Asserting finality status.
Ensuring that the finality status isAcceptedOnL2is a good check to confirm the transaction was processed successfully. Looks solid.
235-235: Test synergy with full resource usage
invoke_transaction_v3_successful_execution_with_all_three_gas_boundsfurther ensures multi-bound coverage. Great addition enhancing ecosystem confidence.
270-270:invoke_transaction_v3_with_invalid_gas_amounts.
Robust negative test for misconfigured L1/L2 gas usage. This aligns well with the new fee validation changes. Well done.
283-283: Checking forInsufficientResourcesForValidate.
Ensures correct error type is returned for invalid resource bounds. This indicates strong alignment between test expectations and your real-world usage scenario.
297-297: Ensuring repeated checks in loop.
The test iterates over multiple invalid configurations. This multiplies coverage and confirms each scenario triggers the expected error. Good approach.
384-384: Zero max fee scenario.
Confirming thatFee(0)triggersInsufficientResourcesForValidateis consistent with prior changes. Looks good.
400-403: Error matching forFee(0).
Correctly matchesTransactionValidationError::InsufficientResourcesForValidatewhen the max fee is zero. This is well-aligned with the new fee validation.
45-45:Details
✅ Verification successful
Sender address extraction.
Constructing theContractAddressfromsn_api_transaction.sender_address()is neat. Just ensure the function always returns a valid, non-zero address for all supported transaction variants.
🏁 Script executed:
#!/bin/bash # Searching usage of `sender_address()` for potential edge cases rg -A 5 "sender_address()"Length of output: 66884
Sender Address Extraction Validity Verified
The grep output confirms that for all invoke and declare transaction variants the code consistently uses a non-zero sender address when constructing a
ContractAddress. There’s no indication of an edge case where a zero address might be returned. However, remember that deploy accounts intentionally yieldNone—this conversion is applied only when a sender address is expected.
153-160:Details
❓ Verification inconclusive
Resource bounds initialization.
ResourceBoundsWrapper::new(...)sets L1/L2 gas usage. Make sure to maintain consistent validation across the codebase—some transactions might require only L1 costs, some might need all three.
🏁 Script executed:
#!/bin/bash rg -A 3 "ResourceBoundsWrapper::new"Length of output: 3387
Action: Verify Consistency of Resource Bounds Initialization
The call in
crates/starknet-devnet-core/src/starknet/add_invoke_transaction.rs:resource_bounds: ResourceBoundsWrapper::new( l1_gas_amount, 1, l1_data_gas_amount, 1, l2_gas_amount, 1, ),mirrors the established pattern seen elsewhere in the codebase. Note that while some transactions (e.g., in
add_declare_transaction.rsorutils.rs) pass hardcoded or zero values for certain gas fields, the invoke transaction uses variable values for all three gas components. Please verify that this difference is intentional and that the invoke transaction rightly requires L1, L1-data, and L2 gas validations as implemented.
- Files to review:
crates/starknet-devnet-core/src/starknet/add_invoke_transaction.rs– Ensure the dynamic gas values (for L1, L1-data, and L2) are correct.- Other modules (like
add_declare_transaction.rsandutils.rs) use constant values in some places; confirm that the variation reflects the intended transaction behavior.crates/starknet-devnet-core/src/starknet/estimations.rs (8)
4-4: No concerns about these new imports.
They appear essential for handling transaction execution flags, transaction logic, gas computation, and error handling.Also applies to: 6-6, 8-8, 16-16
37-45: Verify the nested logic forvalidateflag.
Because thevalidateflag is influenced by bothskip_validate_due_to_impersonationand the optionalvalidateargument, ensure this short-circuit truly covers all intended scenarios without unexpected overrides.
46-53: Implementation of tuple creation looks fine.
The returned triplet neatly encapsulates the transaction object, the validation flag, and the gas vector computation mode.
60-75: Construction ofTransaction::AccountwithExecutionFlagsappears correct.
Usingonly_query: trueensures a read-only estimation, while thecharge_feeandvalidateflags are parameterized properly.
80-91: Error handling for contract execution in simulation is well-defined.
Assigning a uniquefailure_indexclarifies which transaction failed during batch simulations.
129-131: Using the question mark operator to handle transaction execution errors is consistent.
No issues spotted in the direct call totransaction.execute(...).
134-145: Revert handling logic is robust.
All knownRevertErrorvariants are covered. This makes the error path transparent to callers.
148-178: Fee and gas vector calculations are clearly structured.
Transitioning between Strk → FRI and Eth → Wei is properly handled, and the finalFeeEstimateWrapperbreakdown is thorough.crates/starknet-devnet-core/src/starknet/add_deploy_account_transaction.rs (13)
1-1: Import ofExecutionFlagsis appropriate.
This aligns with the usage for transaction execution flags in the added code.
19-20: Sufficient check for zero or invalid max fee.
RaisingInsufficientResourcesForValidateclarifies the issue for the caller.
29-30: Switch tocreate_sn_api_deploy_accountis consistent with new transaction APIs.
This keeps your deploy account flow aligned with the updated SN version.
32-32: No issues with converting the contract address.
Straightforward.into()usage looks correct.
56-67: Creation and execution of the deploy accountAccountTransactionappears accurate.
The newExecutionFlagsusage (with fee charging and validation) follows the updated approach.
76-76: ImportingFeeandTipis fine.
These are likely used in the test coverage and transaction definitions.
114-114: Defining resource bounds with some default zeros is acceptable.
Ensure other potential constraints or resource metrics are not overlooked.
163-165: Error matching onInsufficientResourcesForValidateis precise.
Explicitly capturing this variant in tests is beneficial for clarity.
182-184: Consistent error matching for the V3 scenario.
Ensures uniform behavior across transaction versions.
250-256: Fine approach to create and configure the deploy account transaction in tests.
Any state updates for pre-deployment balances are well-isolated and easy to read.
277-277: Test coverage forInsufficientResourcesForValidateis well-structured.
Guarantees the correct error is surfaced during low-fee deployments.
285-296: Similar deployment logic for the V3 variant is nicely replicated.
Mirroring the V1 test ensures consistent coverage across transaction versions.
408-409:nonzero!(1u128)usage is valid for block context initialization.
No concerns regarding typed constants here.tests/integration/common/background_devnet.rs (8)
22-22: New constantWS_PATHand usage ofHOSTappear aligned with devnet settings.
Including them in the defaults ensures consistency across test environments.
29-29: ImportingSTRK_ERC20_CONTRACT_ADDRESSsuits the updated token usage.
Transition from ETH to STRK is coherent with prior code changes.
37-37: AddingporttoBackgroundDevnetstruct is straightforward.
It helps maintain a reference to the randomly assigned devnet port.
167-169:ws_urlmethod is a clean approach to constructing the WebSocket endpoint.
Generating the URL at runtime avoids hard-coded port references.
223-226: Switching from Wei to Fri in themintmethod is consistent with the updated fee unit.
Please confirm that other references to minted currency and usage contexts are also updated accordingly.
256-256: Refined balance retrieval viaSTRK_ERC20_CONTRACT_ADDRESSis consistent with earlier changes.
Ensures test coverage for your new STRK-based token environment.
289-290: Passingaddressdirectly in JSON is valid.
Formatting is simpler and consistent with typical usage of felt addresses in requests.
386-409:abort_blocksmethod for partial block rollback is a valuable test capability.
Properly returns a list of aborted block hashes, with thorough JSON parsing.crates/starknet-devnet-server/src/api/json_rpc/error.rs (12)
2-2: New import added.
No issues with importingContractExecutionError, it aligns with the usage in this file.
31-33: Expanded error enum to cover contract & transaction execution.
IntroducingContractError(ContractExecutionError)andTransactionExecutionError { failure_index, execution_error }is a clear approach to differentiate these two failure scenarios.
52-53: Renamed/introducedInsufficientResourcesForValidate.
Renaming “InsufficientMaxFee” to “InsufficientResourcesForValidate” clarifies the cause. Good improvement in naming consistency.
66-73: Introduced new error variants for specialized scenarios.
EntrypointNotFound,TooManyBlocksBack,InvalidSubscriptionId, andStorageProofNotSupportedexpand the coverage of possible edge cases and improve diagnostic clarity.
106-112: AddedContractErrormapping in RPC.
Passingcontract_execution_errorin thedatafield for better debugging. This is a practical approach to preserve the revert message.
113-120: Enhanced error reporting withTransactionExecutionError.
Including bothfailure_indexandexecution_errorin the RPC response clarifies where the execution failed and why.
166-170: MappingInsufficientResourcesForValidateto RPC error.
This ties directly to the new variant and ensures correct error reporting.
195-195: TransactionValidationError to ApiError mapping.
ForwardingTransactionValidationError::InsufficientResourcesForValidatetoApiError::InsufficientResourcesForValidatemaintains consistent error flow.
356-368: Tests forApiError::ContractError.
Verifies that the RPC error code (40) and therevert_errorindataare correctly populated. Implementation looks good.
370-389: Tests forApiError::TransactionExecutionError.
These tests confirm proper handling of execution failure index and error message. Looks complete and thorough.
409-425:insufficient_max_fee_errortest renamed & updated.
EnsuresInsufficientResourcesForValidateis triggered when resources are lacking. Logical coverage is good.
483-487: Test helper function for code & data checks.
Enhances test coverage by verifying both error code and data. Implementation is concise and effective.Also applies to: 492-492
crates/starknet-devnet-core/src/starknet/transaction_trace.rs (11)
2-2: New import for error stack tracing.
Bringing inErrorStackis consistent with the revert reason logic below.
6-7: Imports for versioned constants and gas computation mode.
These references align with the new parameters introduced in trace generation.
21-22: Added parameters toget_execute_call_info.
versioned_constantsandgas_vector_computation_modehelp reflect the updated context of transaction execution.
27-31: Passing new execution parameters toFunctionInvocation::try_from_call_info.
This ensures consistent usage of versioned constants and gas settings in the function invocation.
35-38: Enhanced revert reason resolution viarevert_error.
Usingunwrap_orwithErrorStack::default()ensures a fallback in case no revert error is provided.
40-43: Fallback match for missingexecute_call_info.
Properly distinguishes when neither call info nor revert reason is present, returning an error or a revert reason.
58-59: Extendedget_call_info_invocationwith new params.
Similar approach to incorporateversioned_constantsandgas_vector_computation_mode. Implementation looks consistent.Also applies to: 62-67
82-87: Refined trace creation withvalidate_invocation&fee_transfer_invocation.
Both call info retrievals now rely on the new parameters, preserving full compatibility with the upgraded transaction context.Also applies to: 90-95
110-112: Constructor invocation updated.
Propagates the additional parameters to unify contract call logic inDeployAccountTransactionTrace.
120-125: Invoke transaction now retrieves execution invocation.
Aligns with the new function signature forget_execute_call_info.
132-136: L1 handler now uses updatedget_call_info_invocation.
Ensures consistent approach across all transaction types, with appropriate revert scenario handling.crates/starknet-devnet-core/src/starknet/add_declare_transaction.rs (21)
1-1: ImportedExecutionFlags.
This flags struct is now used to control query/fee/validation behavior in transactions.
3-3: Importedcompile_sierra_contract.
Indicates compilation steps for Cairo 1.0 classes are handled directly here.
20-21: Switched toInsufficientResourcesForValidatecheck.
Replacing a max fee zero check with a broader resource validation is more robust and clarifies the real cause of insufficient fees.
30-32: Creating SN API declare transaction.
create_sn_api_declarereplaces the previous blockifier-based approach. This centralizes logic for generating an executable transaction.
33-34: Captured transaction & class hashes.
Storingtx_hashandclass_hashfrom the newly built transaction ensures consistency across the devnet.
73-78: Building and executing the account transaction.
AssemblingAccountTransactionwith updatedexecution_flagsfosters more precise control over fee charging and validation.
80-80: Conditional class addition upon successful execution.
Prevents class registration if the transaction is reverted.
85-85: Hook integration withhandle_accepted_transaction.
Properly logs and finalizes accepted transactions into devnet’s internal structures.
99-101: Compiling & hashing the Cairo 1.0 contract.
Usingcompile_sierra_contractto generate a CASM hash ensures correct verification for Cairo 1.0 classes.
118-118: ImportedFeefromstarknet_api.
Supports new resource-based validation flows that rely on transaction fees.
125-125: ImportedResourceBoundsWrapper.
These bounds factor into fee calculations, further refining the resource validation logic.
132-132: Bringing inHashIdentifiedMut.
This trait usage is consistent with how devnet tracks transactions by unique identifiers.
135-136: New references to dummy functions & contract creation.
These test utilities help generate valid and invalid declare transactions for coverage.
159-159: Clarified error path for query attempts.
Ensures mismatch in transaction type leads toUnsupportedAction.
185-188: Zero max fee triggersInsufficientResourcesForValidate.
This confirms the new resource check is working as expected.
210-213: Similar check for version 2 declare with fee=0.
These lines unify the logic for both declare v2 & v3 transactions under the new error type.
226-227: Insufficient balance error coverage.
ThrowsInsufficientAccountBalanceif the account fails to pay the declared resources.
244-245: Retrieving transaction hash and class hash post-declare.
Ensures the returned values match the transaction results, simplifying test validations.
332-332: Low max fee test for v3 declare.
Verifies that insufficient declared gas resources raiseInsufficientResourcesForValidate. Implementation matches the new logic.Also applies to: 335-341, 343-347
352-352: Not enough account balance test.
Checks that the devnet fails withInsufficientAccountBalanceunder L1 and L2 gas constraints.Also applies to: 355-361, 363-364
370-371: Successful storage change test for v3 declaration.
Demonstrates that sufficient resources lead to a successful declare, with the class properly stored in devnet.Also applies to: 373-379, 381-385, 386-386, 387-387
crates/starknet-devnet-server/src/api/json_rpc/spec_reader/mod.rs (3)
17-19: Ensure naming consistency and clarity for the API method container.Renaming the field from
methods: Vec<ApiMethod>is a helpful step for clarity. Please verify downstream usage to confirm that all references to the oldMethodtype have been removed or updated.
132-155: Verify error handling during request generation.The new parameter type
&ApiMethodappears consistent, but ensure edge cases (e.g., an emptyparamsvector) are handled gracefully. Also, consider adding logs or error details if schema generation fails.
157-162: Confirm robust handling of optional response schemas.
generate_json_rpc_responsegenerates values from an arbitrary schema. Any mismatch or missing fields can lead to deserialization failures downstream. Make sure you have tests covering absent or partial schemas.crates/starknet-devnet-core/src/error.rs (8)
22-28: Approve the new error variants and message structure.Introducing
ContractExecutionErrorandContractExecutionErrorInSimulationwith more detailed context is beneficial. It provides a clear separation between general execution errors and simulation-specific failures.
80-80: EntrypointNotFound variant looks correct.The new variant specifically addressing a missing entry point will help clarify error cases for users, removing ambiguity about potential reasons for transaction failure.
105-106: The new InsufficientResourcesForValidate variant.Replacing
InsufficientMaxFeewith a more generalInsufficientResourcesForValidatevariant clarifies the root cause of validation failure. Ensure that older usage references are updated accordingly.
132-136: PanicInValidate is now mapped to a validation failure.This approach captures panic reasons for reporting. Verify that this conversion doesn't obscure other critical details that might assist debugging (e.g., stack traces).
197-205: InnerContractExecutionError design is sound.The nested structure is well-defined and aids in debugging multi-level calls. Keep an eye on performance overhead if recursion grows large, but it's a solid approach for traceability.
207-215: ContractExecutionError variants are straightforward.Using
Nestedvs. a simpleMessagecovers both structured errors and direct textual errors. This approach is flexible for future expansions in error detail.
225-230: From bridging logic is coherent.Converting
TransactionExecutionErrorintoContractExecutionErrorby generating a stack trace centralizes error handling. Keep testing corner cases to ensure no error variant is overlooked.
322-369: Good approach to building a nested error fromCallInfo.The recursive collection of failed calls fosters in-depth debugging, clarifying precisely which calls fail. This approach is valuable for complex transactions.
crates/starknet-devnet-core/src/account.rs (4)
4-5: Expanded imports provide better clarity on address calculation.Pulling
calculate_contract_address,Calldata, andContractAddressSaltdirectly fromstarknet_api::transaction::fieldsmakes sense for readability and future maintenance.
9-9: Use ofstarknet_types::contract_class::ContractClass.Good choice to unify contract class references under a single consistent type. This helps keep the codebase organized.
52-53: Ensuring correct account class wrapper usage.Adopting
AccountContractClassChoice::Cairo1here centralizes the logic for retrieving the class and class hash, simplifying code and reducing duplication.
152-163: Double-check next storage key usage.
storage_var_address_low.next_storage_key()is invoked twice (for both balance and total supply). Confirm that the key-based arithmetic aligns correctly with the contract's expected storage layout.crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/starknet_ws_api.json (1)
10-37:Details
✅ Verification successful
Validate references to errors and block limits.
The method
"starknet_subscribeNewHeads"referencesTOO_MANY_BLOCKS_BACKandBLOCK_NOT_FOUNDerrors located in separate files. Please verify that these references are valid in the repository and ensure that the 1024-blocks-back limit is consistently enforced across the codebase.
🏁 Script executed:
#!/bin/bash # Verify references to BLOCK_NOT_FOUND and TOO_MANY_BLOCKS_BACK exist in the codebase rg -A 3 'BLOCK_NOT_FOUND' rg -A 3 'TOO_MANY_BLOCKS_BACK'Length of output: 10161
Verification Successful: Error References and Block Limit Enforcement Validated
- Confirmed that the reference to
BLOCK_NOT_FOUNDis correct and its definition exists in multiple spec files (e.g., instarknet_api_openrpc.json).- Confirmed that the
TOO_MANY_BLOCKS_BACKreference is valid instarknet_ws_api.jsonand its error message ("Cannot go back more than 1024 blocks") consistently reflects the 1024-block limit.No further changes are required.
crates/starknet-devnet-core/src/utils.rs (2)
120-144: Tests look well-structured.
dummy_broadcasted_declare_tx_v3function is a clear and readable test helper. The use of dummy data here is appropriate.
72-75:Details
✅ Verification successful
Confirm revert error handling meets your needs.
maybe_extract_failure_reasonsimply convertsexecution_info.revert_errorto aString. Ensure you have no additional data (e.g., error codes) that you might prefer to preserve in a structured format.
🏁 Script executed:
#!/bin/bash # Verify that revert_error is only used as a string across the codebase. rg -A5 'revert_error'Length of output: 8671
Revert Error Handling Consistency Confirmed
The grep search confirms that throughout the codebase (in files such as
src/utils.rs,src/transactions.rs,src/starknet/transaction_trace.rs, and others) therevert_errorfield is consistently handled by converting it to a string. There’s no evidence of additional structured error data (like error codes) being expected or preserved elsewhere, so the current approach inmaybe_extract_failure_reasonappears appropriate for our needs.crates/starknet-devnet-server/src/api/json_rpc/models.rs (3)
198-203: L1 transaction hash input block.
L1TransactionHashInputwith aHash256is clear and straightforward. No issues.
389-395: Reduced transaction length in tests to three.Expanding coverage from
DECLARE V2,INVOKE, andDEPLOY_ACCOUNTis a good approach. The updated assertion ofassert_eq!(estimate_fee_input.request.len(), 3);aligns with the new format.
49-56:Details
❓ Verification inconclusive
Validate presence of optional fields in
GetStorageProofInput.All fields (
class_hashes,contract_addresses,contract_storage_keys) are optional. Ensure upstream code validates that at least one is set, if that is your intended behavior.
🏁 Script executed:
#!/bin/bash # Checking usage for GetStorageProofInput to confirm whether there's validation rg -A10 'GetStorageProofInput'Length of output: 5791
Clarify Optional Fields Validation in
GetStorageProofInputThe struct defines three optional fields—
class_hashes,contract_addresses, andcontract_storage_keys—but the downstream endpoint (inendpoints.rs) doesn’t validate that at least one is provided. If the API’s intention is to require at least one of these fields for a valid storage proof request, please add explicit validation (or update the API documentation/comment) to clarify this behavior.
- File:
crates/starknet-devnet-server/src/api/json_rpc/models.rs(lines 49-56)- Context: The
get_storage_proofendpoint inendpoints.rsonly checks the block ID and immediately returns an error (storage proofs aren’t supported in Devnet), without validating these optional fields.crates/starknet-devnet-server/src/api/json_rpc/endpoints_ws.rs (2)
117-132: Confirm large loop replays.The current loop notifies the subscriber for each old block from
query_block_numberup tolatest_block_number. Verify that for up to 1024 blocks, this won't overly delay other subscribers under high concurrency.
206-226: Verify existing transaction subscription logic.If the transaction hash doesn't exist locally (line 215), the subscription silently continues. Confirm that the user expects no immediate error or a delayed notification once the transaction appears.
crates/starknet-devnet-server/src/api/json_rpc/mod.rs (3)
10-10: Acknowledge RPC version bump.Updating
RPC_SPEC_VERSIONto"0.8.0-rc3"may break certain clients if they strictly check version. Ensure downstream consumers are aware of the version change.
785-840: Evaluate triggers for notifying updates.The
requires_notifying()logic delineates which requests produce block or transaction notifications. Double-check that relevant transactions (e.g., class-declaration transactions) are included if the system requires immediate updates for other client features.
961-1001: Review parsing logic for subscription calls.
to_json_rpc_requestattempts to discern valid subscription variants, returningmethod_not_found()upon mismatch. Confirm that partial or malformed calls yield user-friendly errors in client logs.crates/starknet-devnet-core/src/state/mod.rs (15)
9-9: Confirm usage of new helper function.
The newly importedcompile_sierra_contractis later used for Cairo 1 classes. This looks consistent with the updated logic.
232-232: Check downstream error handling.
Retrieving the compiled class here might fail if it's undeclared, leading to an error. Verify callers handle this properly.
237-237: Mirror compiled class retrieval logic.
This is correct for retrieving the compiled class if it was declared or available from a fork. Ensure consistent usage with line 232’s call.
281-281: Signature alignment for Cairo 1 classes.
ReplacingContractClassparameter withRunnableCompiledClassaligns with the new approach. Confirm all references are updated.
318-325: Refactor to useget_compiled_classand returnRunnableCompiledClass.
This is consistent with the blockifier updates. Implementing the new method name and return type should help unify retrieval logic.
343-347: Ensure consistent checks for declared contracts.
Combining compiled-class-hash checking withget_compiled_classis correct for forking scenarios. Double-check no edge cases remain for partial or incomplete forks.
370-376: Cairo 1 CASM hash linkage.
Computing the CASM hash and storing it in state properly bridges the Sierra contract to its CASM counterpart. This approach seems valid.
430-430: Test import ofContractClass.
This additional import is straightforward, enabling tests for both Cairo 0 and Cairo 1 flows.
433-433: Expanded usage of local traits.
BringingBlockNumberOrPending,CustomState, andCustomStateReaderinto tests helps ensure coverage of the newly introduced functionalities.
434-437: Utility test imports.
The usage ofdummy_cairo_1_contract_class,dummy_felt, etc., streamlines test setup. Confirm these dummy artifacts remain up to date with new Cairo 1 changes.
488-488: New test for declaring Cairo 1 contract class.
A dedicated test fosters reliable coverage of new logic. Reviewing final compiled artifacts to ensure correctness is advisable.
493-493: Post-declaration check.
Verifying throughget_compiled_classafter declaration is a sound approach. This guards against partial or missing state updates.
500-500: Retrieving the dummy Cairo 1 contract.
This usage clarifies how we can support advanced contract tests. Good approach to unify consistent dummy generation across tests.
508-512: Validating compiled class correctness in tests.
Asserting the equality between the retrieved and locally prepared contract ensures that no unexpected transformations are occurring. Good practice.
525-525: Added test for deploying a Cairo 1 contract class.
Extends coverage for the new Cairo 1 logic, ensuring the approach for predeploying or deploying is thoroughly tested.Cargo.toml (5)
39-39: Enable WebSocket support for Axum.
Including thewsfeature is beneficial for streaming or real-time communication. This looks good.
74-74: Upgrade USC to 2.4.0.
Ensure that any breaking changes in the universal-sierra-compiler library have been addressed in the codebase.
81-88: Updated Starknet dependencies.
Incrementing versions forstarknet_api,blockifier, andstarknet-rs-*crates indicates a shift to match the new Cairo 1 & RPC specs. Confirm no regressions in transaction flows or validations.
91-103: Cairo-lang libraries bumped to 2.10.0.
This consistent versioning is crucial for new functionalities. Check for potential compilation or CI issues from these updates.
125-125: Addtokio-tungstenitefor asynchronous WebSockets.
This addition will help implement real-time streaming or subscription-based RPC endpoints. Looks aligned with the WebSocket expansions.crates/starknet-devnet-core/src/starknet/mod.rs (25)
5-5: AddedExecutionModeimport.
Used within the blockifier execution paths, possibly for Sierra or specialized transaction flows.
8-9: AccountTransaction & ExecutionFlags usage.
These changes reflect new transaction flows that may skip or only query the fee. Adjust all references accordingly.
12-13: CASM contract class & H256 dependencies.
CASM usage assists Cairo 1 flow. TheH256fromethersis presumably for bridging or L1-related functionalities.
15-18: Refined block imports for extended gas handling.
IncludingGasPricesand relevant structures provides improved granularity in L1/L2 gas updates. This is consistent with the new approach.
20-21: Data availability and transaction fields.
The additions forDataAvailabilityMode,GasVectorComputationMode, etc. support advanced transaction parameters, matching updated specs.
24-24: Expanded usage of transaction structures.
Pulling in extra fields likeTipor updatedHash256usage for advanced flows. Looks aligned with new transaction version definitions.
27-27: ImportedLocalWallet& signing logic.
For local test net usage, this can streamline transactions requiring mock signing. Ensure no security or leftover debug keys.
125-130: Default Devnet constructor now sets L2 gas prices.
Extending default initialization for L2 gas remains consistent with Cairo 1’s gas model. No issues spotted.
145-150: Initialize block's next gas modifications.
Setting separate data & L2 prices is essential for advanced fee modeling. Good addition to keep the block context consistent.
260-261: Includel2_gas_price_weiandl2_gas_price_fri.
When generating block context, these lines ensure L2 pricing is recognized.
277-278: Expanded GasModification.
Applying these fields ensures we do not lose the L2 gas changes on next block creation. Looks coherent.
323-334: Refreshing pending block with updated gas fields.
Correctly assigns the new GasPrice values into the pending block header. Verify no layering collisions with previous updates.
361-373: Propagating gas price fields into newly accepted blocks.
Ensuring these fields are properly set for each new block helps preserve accurate finalization.
439-439: Gas vector computation retrieval.
Fetchinggas_vector_computation_modedirectly from the transaction clarifies fee strategies. This is a good addition.
447-447: Injecting gas vector mode into trace creation.
Passing the mode ensures the transaction trace can account for advanced resource bounds and tip.
458-458: Block generation after transaction acceptance.
Triggering block creation if needed ensures transactions appear promptly in a new block. This is consistent with on-transaction block generation logic.
465-472: Extended signature forinit_block_context.
Adding L2 gas parameters is consistent with the new Cairo 1 usage for fee calculations.
483-492: Refined block info with new L2 gas price vectors.
Placing L1/L2 gas fields undereth_gas_pricesandstrk_gas_pricesallows dual-currency handling. This is well-structured.
500-503: Storing custom fee token addresses.
Adding an explicit cast fromFeltstrings ensures that EVM-like addresses remain consistent with blockifier.
536-547: Updatingblock_info.gas_pricesinset_block_context_gas.
Constructing these GasPriceVectors from user inputs is correct. Watch for potential mismatches if FRI/Eth pricing diverges drastically.
582-627: Restarting pending block with multi-gas pricing.
This large block sets the new block header fields for L1 and L2 prices in both wei and FRI. Looks consistent with the newly introduced structure.
822-843: New internal functionminting_calldata.
Constructing correct ERC20 transfer calls is critical. Summarizing the call data in one place is clean and maintainable.
859-877: Building an Invoke V3 transaction for mint.
Populating resource bounds and paymaster data ensures compliance with advanced transaction format.
882-889: Local wallet signing flow.
Signing the transaction hash for an Invoke V3 flow is consistent with the standard approach. Consider negative tests for invalid keys.
891-891: Assigning signature to invoke transaction.
Ensures the final constructed transaction includes the signature fields. This paralleling of standard signing steps is good practice.crates/starknet-devnet-server/src/subscribe.rs (2)
28-35: Looks good.The
get_mutmethod properly handles missing socket IDs by returningApiError, ensuring robust error reporting. No issues identified.
135-164: No issues found.Creation of
SubscriptionConfirmationandTransactionHashWrapperlooks correct, and the serialization/deserialization logic appears consistent.
| - path: components/schemas/CellRef/properties/offset | ||
| new_entry: maximum/32767 |
There was a problem hiding this comment.
💡 Verification agent
❓ Verification inconclusive
Potential YAML Syntax Issue in “CellRef” Entry
The new entry for the CellRef offset property uses:
new_entry: maximum/32767
This syntax is unconventional for YAML. It is likely that the intended format is something like maximum: 32767. Please verify and adjust if necessary. For example:
- new_entry: maximum/32767
+ new_entry: maximum: 32767YAML Syntax Correction Required
The snippet at crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/edit_spec_instructions.yaml (lines 28-29) uses unconventional YAML syntax by specifying the value with a slash (maximum/32767). To follow standard YAML conventions—and likely reflect the intended schema—the entry should be revised to use a colon separator. For example:
- new_entry: maximum/32767
+ new_entry: maximum: 32767Please update the YAML accordingly to ensure proper parsing.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - path: components/schemas/CellRef/properties/offset | |
| new_entry: maximum/32767 | |
| - path: components/schemas/CellRef/properties/offset | |
| new_entry: maximum: 32767 |
| - action: REMOVE | ||
| what: starknet_getBlockWithTxs -> result removed PENDING_BLOCK_WITH_TXS | ||
| what: remove the outer object of CASM_COMPILED_CONTRACT_CLASS.hints property |
There was a problem hiding this comment.
💡 Verification agent
❓ Verification inconclusive
Critical Change: Removal of starknet_getStorageProof Method
The explicit removal of the starknet_getStorageProof method is a breaking change. Ensure that any consumers or API clients are informed of this removal and that the migration path or replacements are clearly documented.
#!/bin/bash
# Searching for references to 'starknet_getStorageProof' in the repository
rg "starknet_getStorageProof" -n .Based on our verification so far, the diff snippet in
crates/starknet-devnet-server/test_data/spec/0.8.0-rc3/edit_spec_instructions.yaml (lines 64–65) only shows the removal of the outer object for the CASM_COMPILED_CONTRACT_CLASS.hints property. There is no diff evidence in this file explicitly showing the removal of the starknet_getStorageProof method.
Critical Change: Removal of starknet_getStorageProof Method
- The provided diff only indicates a removal related to the hints property. Please double-check that the removal of
starknet_getStorageProofis fully implemented and documented elsewhere in the codebase. - Ensure that all references to
starknet_getStorageProofhave been removed and that this breaking change is clearly communicated to API consumers. - Update the migration documentation and any affected tests or client interfaces to guide users on the transition or alternative functionality.
| impl TryFrom<Cairo0ContractClass> for RunnableCompiledClass { | ||
| type Error = Error; | ||
|
|
||
| fn try_from(class: Cairo0ContractClass) -> Result<Self, Self::Error> { | ||
| Ok(RunnableCompiledClass::V0(match class { | ||
| Cairo0ContractClass::RawJson(cairo0_json) => serde_json::from_value(cairo0_json.inner) | ||
| .map_err(|e| { | ||
| Error::ConversionError(ConversionError::InvalidInternalStructure(e.to_string())) | ||
| })?, | ||
| Cairo0ContractClass::Rpc(deprecated_contract_class) => { | ||
| let deserializer = deprecated_contract_class.program.into_deserializer(); | ||
| let program = deserialize_program(deserializer).map_err(|e| { | ||
| Error::ConversionError(ConversionError::InvalidInternalStructure(e.to_string())) | ||
| })?; | ||
|
|
||
| fn convert_to_entrypoints_v0<'a, I>(entry_points: I) -> Vec<EntryPointV0> | ||
| where | ||
| I: Iterator<Item = &'a LegacyContractEntryPoint>, | ||
| { | ||
| entry_points | ||
| .map(|entry_point| EntryPointV0 { | ||
| selector: starknet_api::core::EntryPointSelector(entry_point.selector), | ||
| offset: EntryPointOffset(entry_point.offset as usize), | ||
| }) | ||
| .collect() | ||
| } | ||
|
|
||
| let mut entry_points_by_type = HashMap::new(); | ||
| entry_points_by_type.insert( | ||
| EntryPointType::Constructor, | ||
| convert_to_entrypoints_v0( | ||
| deprecated_contract_class.entry_points_by_type.constructor.iter(), | ||
| ), | ||
| ); | ||
|
|
||
| entry_points_by_type.insert( | ||
| EntryPointType::External, | ||
| convert_to_entrypoints_v0( | ||
| deprecated_contract_class.entry_points_by_type.external.iter(), | ||
| ), | ||
| ); | ||
|
|
||
| entry_points_by_type.insert( | ||
| EntryPointType::L1Handler, | ||
| convert_to_entrypoints_v0( | ||
| deprecated_contract_class.entry_points_by_type.l1_handler.iter(), | ||
| ), | ||
| ); | ||
|
|
||
| CompiledClassV0(Arc::new(CompiledClassV0Inner { program, entry_points_by_type })) | ||
| } | ||
| })) | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Check for large sums of lines in the conversion logic.
This extensive chunk maps Cairo0 JSON or RPC forms to a RunnableCompiledClass::V0. It’s critical to ensure that each step (like event points, entrypoint offsets) remain accurate after the removal of older transaction versions. Also confirm concurrency safety if this method is invoked in multi-threaded contexts.
| AllResourceBounds, Fee, GasVectorComputationMode, Tip, ValidResourceBounds, | ||
| }; | ||
| use starknet_api::transaction::{signed_tx_version, TransactionHasher, TransactionOptions}; | ||
| use starknet_rs_core::types::{ |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Ensure thorough signed version validations.
signed_tx_version might produce unexpected results when dealing with version offsets. Validate coverage in unit or integration tests for flattened transaction versions.
| "type": "string" | ||
| } | ||
| }, | ||
| "required": "compilation_error" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Confirm usage of the "required" property.
The field "required": "compilation_error" is not the conventional JSON Schema approach—usually "required" expects an array. If this is intended, clarify or confirm tooling compatibility. Otherwise, consider:
- "required": "compilation_error"
+ "required": ["compilation_error"]📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "required": "compilation_error" | |
| "required": ["compilation_error"] |
| { | ||
| "$ref": "#/components/errors/COMPILATION_ERROR" | ||
| }, | ||
| { | ||
| "$ref": "./api/starknet_api_openrpc.json#/components/errors/CLASS_HASH_NOT_FOUND" | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Validate external error references.
References to CLASS_HASH_NOT_FOUND point to a path in starknet_api_openrpc.json. Please ensure that ./api/starknet_api_openrpc.json#/components/errors/CLASS_HASH_NOT_FOUND is valid from this file’s location and properly defined in that file.
Run a shell script to confirm the file includes this error definition:
🏁 Script executed:
#!/bin/bash
rg --context 5 'CLASS_HASH_NOT_FOUND' ./api/starknet_api_openrpc.jsonLength of output: 141
The initial verification indicates that the file path ./api/starknet_api_openrpc.json does not exist relative to the location of starknet_executables.json. This means that the reference to #/components/errors/CLASS_HASH_NOT_FOUND cannot be validated.
Action Required:
- Verify that
starknet_api_openrpc.jsonexists in the intended location relative tocrates/starknet-devnet-server/test_data/spec/0.8.0-rc3/. If it’s located elsewhere, update the relative path accordingly. - Ensure that the error definition for
CLASS_HASH_NOT_FOUNDis properly defined under/components/errorsin the referenced JSON file.
🏁 Script executed:
#!/bin/bash
fd --type f "starknet_api_openrpc.json"Length of output: 242
Action Required: Correct External Reference Path
- The file search confirmed that
starknet_api_openrpc.jsonis located atcrates/starknet-devnet-server/test_data/spec/0.8.0-rc3/starknet_api_openrpc.json, not in anapisubdirectory. - Thus, the reference in
starknet_executables.json("./api/starknet_api_openrpc.json#/components/errors/CLASS_HASH_NOT_FOUND") does not resolve correctly. - Suggestion: Either update the reference to
"./starknet_api_openrpc.json#/components/errors/CLASS_HASH_NOT_FOUND"if the JSON file is meant to reside in the same folder, or move the file into theapisubdirectory so that the reference remains valid.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
tests/integration/test_deploy.rs (1)
38-40: Clarify or centralize the numeric gas limits.
Using.l1_gas(0).l1_data_gas(1000).l2_gas(5e7 as u64)is valid for testing different resource bounds. Consider extracting these numeric values into named constants or doc commentary for clarity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
tests/integration/common/constants.rs(3 hunks)tests/integration/test_deploy.rs(3 hunks)tests/integration/test_old_state.rs(9 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- tests/integration/common/constants.rs
🧰 Additional context used
🧬 Code Definitions (1)
tests/integration/test_old_state.rs (4)
tests/integration/common/utils.rs (6)
assert_cairo1_classes_equal(204-218)extract_message_error(462-467)extract_nested_error(470-475)new(233-238)from(596-611)from(615-639)crates/starknet-devnet-types/src/rpc/transactions.rs (4)
new(127-129)new(359-383)from(346-352)from(396-424)crates/starknet-devnet-core/src/error.rs (8)
from(84-86)from(116-138)from(142-151)from(155-175)from(217-219)from(226-229)from(251-319)from(323-368)tests/integration/test_advancing_time.rs (1)
devnet(178-184)
🔇 Additional comments (20)
tests/integration/test_deploy.rs (3)
4-10: Added error-related and account imports look appropriate.
These new imports (e.g.,AccountError,StarknetError,TransactionExecutionErrorData) align with the enhanced error handling and structured error matching below. No issues noted.
14-19: Additional constants and utility imports appear consistent.
Bringing inCAIRO_1_ACCOUNT_CONTRACT_SIERRA_HASH,UDC_CONTRACT_ADDRESS,UDC_CONTRACT_CLASS_HASH, and the helper functions supports the detailed error verifications that follow.
56-80: Well-structured error-handling and nested validation.
This thorough match arms the test against multiple levels of transaction errors, ensuring granular verification of contract address, class hash, and error messages. Implementation looks correct and robust.tests/integration/test_old_state.rs (17)
3-5: Importing default Devnet gas prices is appropriate for new resource bounds.
No issues with referencing these constants; they fit well into the revised gas usage requirements.
20-20: Added UDC addresses and class hashes.
These constants are correctly brought in, matching references in subsequent deployment calls and error checks.
23-24: Utility and comparison function imports.
New imports forassert_cairo1_classes_equal,extract_message_error, andextract_nested_errorare consistent with deeper validation logic introduced later.
51-51: Switch to.execute_v3aligns with newer transaction version.
Upgrading from older transaction calls is coherent with the rest of the codebase changes to version 3.
97-97: Changed fee unit toFeeUnit::Fri.
This modifies how balances are interpreted when retrieving minted amounts. Please confirm that usage in other tests or code paths expects this same unit to avoid subtle mismatches.
113-115: Renamed test method and updated doc for clarity.
The new name better reflects the test scenario. No functional issues found.
143-143: Upgrading to.declare_v3for class declaration.
This matches the updated transaction versioning across the codebase. Implementation is consistent.
146-147: Selector calculation and salt assignment.
These lines correctly set up parameters for contract deployment. No issues.
150-151: UDC contract call definitions.
Definingto: UDC_CONTRACT_ADDRESSandselector: udc_selectoris coherent with UDC-based deployment logic.
154-168: New closure constructing query call transaction.
Creating aBroadcastedInvokeTransactionV3inline is fine for test readability. The code is clear, and resource bounds are delegated externally.
174-178: Zero gas resource bounds for error scenario.
Setting all max amounts and prices to zero helps ensure a transaction fails predictably for negative testing. This is a valid approach.
189-202: Partial usage of Devnet defaults for resource bounds.
Combining zero forl1_gas.max_amountwith default gas prices ensures a different scenario from the all-zero case. Looks correct for coverage.
208-210: Preparing a clear error message string.
Setting an explicit message for class hash not declared is helpful for the subsequent error verification.
211-240: Detailed nested error validation.
The multi-level extraction of contract addresses, selectors, and error messages is thoroughly verified. This robust approach ensures each nested error is expected.
246-248: Confirming revert reason in the transaction trace.
Ensuring the test checks for proper revert context is a good addition; it strengthens coverage for failing transactions.
271-274: Refined gas parameters in.declare_v3call.
Similar to previous tests, specifying separate L1/L2 gas allocations is consistent with new resource-bound patterns.
338-338: Updated.execute_v3call usage.
This final shift to version 3 keeps the code consistent with transaction-flow changes.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (13)
crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_executables.json (1)
1-8: File Header and Basic Info
The header correctly sets the OpenRPC version and provides basic metadata (version, title, and license). Consider populating the license details if applicable.crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_trace_api_openrpc.json (4)
1-7: Review File Header and License Information
The header information (OpenRPC version, API version, and title) is clear and well structured. However, the"license": {}field is empty. Consider either providing the appropriate license details or removing the field if not applicable.
40-104: Method "starknet_simulateTransactions": Comprehensive Simulation Capability
The method effectively captures simulation requirements:
- Parameters include a block identifier, a sequence of transactions, and simulation flags.
- The result schema details both transaction trace and fee estimation.
The description is rich but slightly repetitive regarding revert behavior. A minor refinement to the documentation might boost clarity.
148-288: Schema "TRANSACTION_TRACE": Detailed Trace Definitions
The schema utilizes aoneOfconstruct to differentiate between various transaction trace types (invoke, declare, deploy account, L1 handler). This provides flexibility and clarity in representing diverse transaction outcomes. Consider including inline examples or more detailed descriptions for each trace type to further aid API consumers in understanding the expected structure of responses.
427-444: Schema "INNER_CALL_EXECUTION_RESOURCES": Execution Resources Breakdown
The schema clearly delineates between L1 and L2 gas consumption. Consider verifying whether theintegertype is sufficient for representing very large gas values or if an alternative numeric representation might be necessary.crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_write_api.json (3)
1-7: Write API File Header: Metadata Verification
The header sets the OpenRPC version and API details (version 0.8.0 and title "StarkNet Node Write API") appropriately. Similar to the trace API file, consider populating the"license"field if applicable to the project or removing it if not needed.
64-137: Method "starknet_addDeclareTransaction": Class Declaration Transaction
This method captures the key aspects of a declare transaction, including the dual output of both transaction and class hashes. The error responses are extensive and cover compilation and validation concerns. Note the message for"CONTRACT_CLASS_SIZE_IS_TOO_LARGE"—a minor grammatical refinement (e.g., "Contract class size is too large") could enhance clarity.
228-285: Components Errors: Comprehensive Error Definitions
The error definitions are detailed and mirror those in the trace API, ensuring consistency. Consider revising the phrasing for"NON_ACCOUNT"(currently "Sender address in not an account contract") to improve grammatical clarity (e.g., "Sender address is not an account contract").crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_ws_api.json (3)
1-7: Consider providing more complete license information.
Currently, the"license"field is an empty object. Providing at least the license name and URL (if applicable) can help clarify the licensing terms.- "license": {} + "license": { + "name": "Apache-2.0", + "url": "https://www.apache.org/licenses/LICENSE-2.0" + }
220-220: Typo: "tranasaction" => "transaction".- "description": "Either a tranasaction hash or full transaction details, based on subscription", + "description": "Either a transaction hash or full transaction details, based on subscription",
288-345: Potential filter enhancements.
The existing subscriptions allow partial filtering (e.g., block range). For advanced usage, consider adding additional filter fields (e.g., sorting or advanced event matching). This is not strictly required, but would provide more flexible subscription queries.crates/starknet-devnet-server/src/api/json_rpc/mod.rs (2)
277-286: Empty block fallback for tags "latest" or "pending".
The fallback to an empty accepted block is practical for internal conveniences. However, be aware that external consumers might be confused if the response implies a valid block when none actually exists. Consider an optional result or an error message if appropriate.
288-342: Log or handle scenario when no transactions changed in pending block.
The logic only broadcasts changes if new pending transactions are found. For improved traceability, you may want to log or handle the scenario when nothing was broadcast, to ensure subscription debugging is easier.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
crates/starknet-devnet-server/src/api/json_rpc/mod.rs(18 hunks)crates/starknet-devnet-server/test_data/spec/0.8.0/edit_spec_instructions.yaml(3 hunks)crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_executables.json(1 hunks)crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_trace_api_openrpc.json(1 hunks)crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_write_api.json(1 hunks)crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_ws_api.json(1 hunks)tests/integration/general_rpc_tests.rs(3 hunks)
🧰 Additional context used
🧬 Code Definitions (1)
crates/starknet-devnet-server/src/api/json_rpc/mod.rs (7)
crates/starknet-devnet-server/src/rpc_core/response.rs (4)
error(43-45)error(66-68)from_rpc_error(27-29)new(19-21)crates/starknet-devnet-server/src/api/json_rpc/models.rs (9)
serde_json(292-292)serde_json(387-387)serde_json(401-401)serde_json(424-424)serde_json(581-581)serde_json(594-594)serde_json(607-607)serde_json(623-623)serde_json(636-636)crates/starknet-devnet-server/src/api/json_rpc/endpoints.rs (2)
estimate_message_fee(346-361)call(301-322)crates/starknet-devnet-server/src/server.rs (3)
rpc_handler(58-58)rpc_handler(59-59)rpc_handler(60-60)crates/starknet-devnet-server/src/rpc_handler.rs (2)
on_call(37-37)on_websocket(40-40)crates/starknet-devnet-server/src/rpc_core/request.rs (1)
id(26-28)crates/starknet-devnet-server/src/rpc_core/error.rs (2)
method_not_found(30-32)invalid_params(45-50)
🔇 Additional comments (44)
tests/integration/general_rpc_tests.rs (3)
2-2: Import addition is appropriate.The new import
starknet_rs_core::types::BlockIdis correctly added as it's needed for the new test function.
27-27: Version update aligns with RPC spec upgrade.The version string update from "0.7.1" to "0.8.0" correctly corresponds to the PR objective of updating to RPC version 0.8.
55-73: Well-structured test for storage proof error handling.This new test function comprehensively tests the error handling of
starknet_getStorageProofRPC method with multiple scenarios:
- Missing required field
- Unsupported feature (with multiple block ID formats)
- Non-existent block
The test ensures proper error codes and messages are returned in each case, which is essential for API stability.
crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_executables.json (5)
9-41: Definition of Methodstarknet_getCompiledCasm
The method is well defined with a clear summary, required parameter (class_hash), and a proper result schema reference. Note that the errors array references one local error (COMPILATION_ERROR) and another external reference (./api/starknet_api_openrpc.json#/components/errors/CLASS_HASH_NOT_FOUND). Please verify that the external reference is valid relative to the repository structure.
45-125: Schema: CASM_COMPILED_CONTRACT_CLASS
This schema outlines the expected structure of the compiled contract class, including key properties such asentry_points_by_type,bytecode,prime,compiler_version, andhints. The constraints on the array (e.g.,minItemsandmaxItemsfor hints) look reasonable. Verify that these constraints accurately reflect the underlying data requirements.
127-148: Schema: CASM_ENTRY_POINT
The CASM_ENTRY_POINT schema is clearly defined, requiring theoffset,selector, andbuiltinsproperties. The reference to the externalFELTschema for theselectoris consistent with the rest of the spec.
42-1344: Components and Schemas Overview
The file contains a comprehensive list of schemas (such asCellRef,Deref,DoubleDeref, etc.) that detail various data structures used across the API. Most references (e.g., to external definitions likeFELTandNUM_AS_HEX) appear to be correctly set up. As this file is newly introduced, please double-check that all external$refpaths (including those pointing to./api/starknet_api_openrpc.json) resolve correctly within the repository setup.
1362-1364: Finalizing the Specification
The closing lines of the JSON file appropriately wrap up the specification. Overall, this OpenRPC spec is comprehensive and aligns with the changes in the PR objectives. Just ensure that the references to external schemas and error definitions are verified against the repository structure.crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_trace_api_openrpc.json (8)
9-39: Method "starknet_traceTransaction": API Trace Retrieval
This method is defined with clear parameter, result, and error structures. The reference to the transaction hash schema and usage of the trace schema are appropriate. Ensure that the external reference (./api/starknet_api_openrpc.json#/components/schemas/TXN_HASH) is valid and maintained in sync with the rest of the API specifications.
105-143: Method "starknet_traceBlockTransactions": Block-Level Trace Retrieval
This method cleanly defines the retrieval of transaction traces for an entire block using a straightforward parameter and response schema. Double-check that the use of"trace_root"as the property name (referencingTRANSACTION_TRACE) aligns with the overall design semantics.
289-293: Schema "SIMULATION_FLAG": Simulation Flags Enumeration
The enumeration defining simulation flags is concise and clear. The description and allowed values ("SKIP_VALIDATE", "SKIP_FEE_CHARGE") precisely communicate the intended behavior during simulations.
297-378: Schema "FUNCTION_INVOCATION": Merging Function Call Attributes
By usingallOfto extend the baseFUNCTION_CALLschema with additional properties (caller_address, class_hash, entry_point_type, etc.), the design cleanly encapsulates extended invocation details. Verify that the required fields list comprehensively covers all data needed for proper trace reconstruction.
379-386: Schemas "ENTRY_POINT_TYPE" and "CALL_TYPE": Enumerations
The enumerations succinctly list allowed values for entry point types and call types. They are consistent with expected API behavior.
387-426: Schemas "ORDERED_EVENT" and "ORDERED_MESSAGE": Handling Order Context
UsingallOfto combine an order property with additional event/message schemas is a good strategy for preserving execution order metadata. This approach provides clarity in the API response structure.
445-472: Schema References: External Dependencies Integration
Several schemas (e.g.,FELT,FUNCTION_CALL,EVENT_CONTENT, etc.) are referenced from an external API file. Ensure that these external definitions are consistent, up-to-date, and adequately documented to avoid integration issues.
473-488: Error Schema "NO_TRACE_AVAILABLE": Clear Error Definition
The error definition is concise with code 10 and properly defines the structure of additional error information. Confirm that the dual status values ("RECEIVED" and "REJECTED") capture all necessary failure contexts for downstream error handling.crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_write_api.json (3)
10-63: Method "starknet_addInvokeTransaction": Transaction Submission Structure
The definition for adding an invoke transaction is clear with well-defined parameters and result schemas. The error list covers a broad range of potential issues. Ensure that the referenced schema forBROADCASTED_INVOKE_TXNcomprehensively defines all required fields for a valid invoke transaction.
138-198: Method "starknet_addDeployAccountTransaction": Deploy Account Workflow
The method definition is clear, with the required parameter and result structure. Pay attention to the external error reference forCLASS_HASH_NOT_FOUNDand verify that it is consistent across the API suite.
200-227: Components Schemas: External References and Consistency
The components include several schemas (e.g.,NUM_AS_HEX,SIGNATURE,FELT, etc.) that are pulled from external definitions. It is important to verify that all these references are accurate and maintained properly with any upstream changes in thestarknet_api_openrpc.jsonfile.crates/starknet-devnet-server/test_data/spec/0.8.0/edit_spec_instructions.yaml (15)
7-7: Rename key to "replace_property" for clarity.
Changing from a generic "replace" to "replace_property" makes the intent explicit in the spec processing.
11-14: Update schema property names to "tuple".
The updates for bothCASM_COMPILED_CONTRACT_CLASSandDoubleDerefcorrectly rename the property to "tuple", which improves consistency and clarity in the schema definitions.
19-19: Set replace_mode flag for NUM_AS_HEX.
Introducing"replace_mode: true"ensures that the new entry forNUM_AS_HEXproperly overrides the old format. Please verify that the processing logic treats this flag as intended.
28-29: Define maximum value constraint for CellRef offset.
Adding the entrymaximum/32767sets an upper bound for the offset. Confirm that your spec parser correctly interprets this value format and enforces it as a numeric maximum.
49-52: Verify removal indices in remove_from_array.
The updated removal commands forDECLARE_TXN(indices 1 then 0) and forHINT(index 0) may shift array positions when applied sequentially. Please double-check that the removal order produces the intended final array structure.
58-59: Include execution_status in TXN_STATUS_RESULT requirements.
Addingexecution_statusto the required array aligns the spec with new transaction result expectations. Ensure that all downstream consumers and tests adjust accordingly.
60-61: Require ABI in CONTRACT_CLASS definitions.
Makingabia required field enhances contract validation and consistency. Please confirm that documentation and integrations have been updated to reflect this change.
63-63: Remove outdated SYNC_STATUS variant from starknet_syncing.
Eliminating theoneOf SYNC_STATUSvariant cleans up the spec to match current API designs. Verify that all related components no longer depend on this variant.
65-65: Deprecate the starknet_getStorageProof method.
Removing this deprecated method signals its obsolescence. Ensure that API clients and documentation are updated to prevent accidental use.
67-67: Simplify CASM_COMPILED_CONTRACT_CLASS.hints structure.
Removing the outer object reduces nesting and clarifies the data structure. Confirm that converters and validators have been adapted to handle the flattened format.
69-69: Streamline DoubleDeref.hints schema.
Eliminating the extra "types, items" wrapping promotes a simpler schema. Please verify that any parsers or tools relying on the previous structure are updated.
71-71: Enforce maximum constraint on DoubleDeref tuple.
Introducing a maximum of 32767 establishes strict bounds for the tuple’s integer part. Ensure that this limit is in line with your business rules and that validation logic enforces it properly.
73-73: Flatten schema in starknet_simulateTransactions responses.
Removing the outer"schema"object simplifies the response structure by directly exposing{type, properties}. Confirm that all consumers and tests are operating with the new, flattened format.
79-79: Simplify REORG_DATA block hash object.
The removal of the outer schema object forstarting_block_hashandending_block_hashinstarknet_ws_api.jsonstreamlines the response. Please ensure that clients parsing these values adjust to the new format.
80-81: Refine FELT regex for improved validation.
Updating the pattern to^0x(0|[a-fA-F1-9]{1}[a-fA-F0-9]{0,61})$enhances validation of FELT values by enforcing stricter hex formatting rules. Double-check that it covers all valid cases and excludes incorrect ones.crates/starknet-devnet-server/src/api/json_rpc/mod.rs (10)
2-2: WebSocket endpoints module inclusion looks good!
The newendpoints_wsmodule integrates well with the rest of the JSON-RPC code.
10-10: RPC spec version update aligns with 0.8.0 changes.
No issues; the change correctly reflects the new specification version.
161-178: Validate correctness ofrequires_notifyingcondition.
Several additional request types trigger post-execution notifications (e.g., minted tokens, new transactions). This logic looks consistent with the newly introduced WebSocket subscription flows. Just ensure any future modifications to transaction-based calls also appear here, preventing missed notifications.
197-200: Graceful handling of broadcaster errors.
Ifbroadcast_changesfails, the method returns an error result immediately. This ensures the user is informed of the failure, but it may also stop subsequent operations or notifications. Confirm that an error here does not leave partial changes in a problematic state for the devnet.
430-457: Reorg detection logic.
The iteration from the old latest block to the orphaned successor of the new latest block is effective. If reorg depths get large, consider verifying performance. Otherwise, this approach is fine for typical usage.
483-495: Newget_compiled_casmrequest.
This integration looks correct but ensure that actual usage of the method checks for class hash validity or presence. Otherwise, it could result in ambiguous errors if the class hash is unknown.
589-591: Confirm the correctness of new request methods for messages status and storage proof.
These methods appear to be newly introduced. Verify they function as intended and are fully tested, especially for boundary cases like nonexistent L1 transaction hashes or partial storage proofs.
961-1001: Subscription request enumeration.
Adding new subscription types (e.g.,NewHeads,TransactionStatus, etc.) appears coherent with the WebSocket specification. Ensure any expansions in the JSON spec file (e.g., new subscription variants) are reflected here with matching naming.
1010-1011: Large variant allowance is good.
Allowing for larger enum variants can simplify the API but keep an eye on compilation warnings or performance overhead in the long run.
1032-1065: Signed transaction status expansions.
The new variants withinStarknetResponse(such asMessagesStatusByL1Hash) accommodate a broader set of devnet use cases. Looks appropriate for advanced debugging.
crates/starknet-devnet-server/test_data/spec/0.8.0/starknet_executables.json
Show resolved
Hide resolved
| "name": "starknet_unsubscribe", | ||
| "summary": "Closes a websocket subscription", | ||
| "description": "Close a previously opened ws stream, with the corresponding subscription id", | ||
| "params": [ | ||
| { | ||
| "name": "subscription_id", | ||
| "summary": "The subscription to close", | ||
| "required": true, | ||
| "schema": { | ||
| "type": "integer" | ||
| } | ||
| } | ||
| ], | ||
| "result": { | ||
| "name": "Unsubscription result", | ||
| "description": "True if the unsubscription was successful", | ||
| "schema": { | ||
| "type": "boolean" | ||
| } | ||
| }, | ||
| "errors": [ | ||
| { | ||
| "$ref": "#/components/errors/INVALID_SUBSCRIPTION_ID" | ||
| } | ||
| ] | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Ensure unsubscribe logic aligns with the subscription ID type.
The JSON specification requires a "type": "integer" for subscription_id, while other parts of the ecosystem may use strings or FELTs. Confirm that the server consistently treats it as an integer to avoid mismatch with external clients or confusion in typed languages.
🏁 Script executed:
#!/bin/bash
# Check references to `subscription_id` usage in the codebase for consistency.
rg -A 3 '"subscription_id"' | grep -E 'type|schema|integer|string'Length of output: 2171
Ensure consistent subscription ID schema usage
It appears that while the unsubscribe endpoint currently defines subscription_id inline with "type": "integer", other parts of the spec consistently reference it via "$ref": "#/components/schemas/SUBSCRIPTION_ID". Please verify that both definitions are equivalent. If the common schema is meant to be used throughout, update the unsubscribe endpoint to reference #/components/schemas/SUBSCRIPTION_ID to prevent any type mismatches or confusion with external clients.
|
@coderabbitai configuration |
CodeRabbit configurationlanguage: en-US
tone_instructions: ''
early_access: false
enable_free_tier: true
auto_resolve_threads: true
reviews:
profile: chill
request_changes_workflow: false
high_level_summary: true
high_level_summary_placeholder: '@coderabbitai summary'
high_level_summary_in_walkthrough: false
auto_title_placeholder: '@coderabbitai'
auto_title_instructions: ''
review_status: true
commit_status: true
fail_commit_status: false
collapse_walkthrough: false
changed_files_summary: true
sequence_diagrams: true
assess_linked_issues: true
related_issues: true
related_prs: true
suggested_labels: true
auto_apply_labels: false
suggested_reviewers: true
auto_assign_reviewers: false
poem: true
labeling_instructions: []
path_filters: []
path_instructions: []
abort_on_close: true
auto_review:
enabled: true
auto_incremental_review: true
ignore_title_keywords: []
labels: []
drafts: false
base_branches: []
finishing_touches:
docstrings:
enabled: true
tools:
shellcheck:
enabled: true
ruff:
enabled: true
markdownlint:
enabled: true
github-checks:
enabled: true
timeout_ms: 90000
languagetool:
enabled: true
enabled_only: false
level: default
biome:
enabled: true
hadolint:
enabled: true
swiftlint:
enabled: true
phpstan:
enabled: true
level: default
golangci-lint:
enabled: true
yamllint:
enabled: true
gitleaks:
enabled: true
checkov:
enabled: true
detekt:
enabled: true
eslint:
enabled: true
rubocop:
enabled: true
buf:
enabled: true
regal:
enabled: true
actionlint:
enabled: true
pmd:
enabled: true
cppcheck:
enabled: true
semgrep:
enabled: true
circleci:
enabled: true
sqlfluff:
enabled: true
chat:
auto_reply: true
create_issues: true
integrations:
jira:
usage: auto
linear:
usage: auto
knowledge_base:
opt_out: false
web_search:
enabled: true
learnings:
scope: auto
issues:
scope: auto
jira:
usage: auto
project_keys: []
linear:
usage: auto
team_keys: []
pull_requests:
scope: auto
code_generation:
docstrings:
language: en-US
|
|
@CodeRabbit How do I configure you to skip files in |
|
Tip For best results, initiate chat on the files or code changes. @FabijanC To skip files in the Add the following to your configuration YAML: path_filters:
- "!crates/starknet-devnet-server/test_data/spec/**"The You can apply this change in your repository's |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
crates/starknet-devnet-core/src/starknet/mod.rs (2)
756-756: TODO comment needs resolution.There's a TODO comment referring to a Slack conversation without providing context for future maintainers. Please add more details or resolve the TODO.
- // TODO other cases: https://spaceshard.slack.com/archives/C03QN20522D/p1735547866439019 + // TODO: Handle other execution failure cases (see discussion: https://spaceshard.slack.com/archives/C03QN20522D/p1735547866439019) + // - Consider cases like out of gas, arithmetic errors, etc.
689-691: New method for compiled CASM retrieval looks good.The
get_compiled_casmmethod provides a clean interface to retrieve compiled CASM contract classes. Consider adding a brief doc comment to improve code clarity.+ /// Retrieves the compiled CASM contract class for a given class hash. + /// This is useful for clients that need to access compiled code. pub fn get_compiled_casm(&self, class_hash: ClassHash) -> DevnetResult<CasmContractClass> { get_class_impls::get_compiled_casm_impl(self, class_hash) }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.circleci/config.yml(2 hunks)crates/starknet-devnet-core/src/starknet/mod.rs(38 hunks)docker/Dockerfile(2 hunks)rust-toolchain.toml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- rust-toolchain.toml
- .circleci/config.yml
- docker/Dockerfile
🧰 Additional context used
🧬 Code Definitions (1)
crates/starknet-devnet-core/src/starknet/mod.rs (5)
crates/starknet-devnet-types/src/rpc/transactions.rs (6)
gas_vector_computation_mode(106-115)gas_vector_computation_mode(528-541)new(127-129)new(359-383)from(346-352)from(396-424)crates/starknet-devnet-core/src/starknet/transaction_trace.rs (1)
create_trace(73-149)crates/starknet-devnet-core/src/starknet/get_class_impls.rs (1)
get_compiled_casm_impl(58-71)crates/starknet-devnet-types/src/rpc/transactions/invoke_transaction_v3.rs (1)
new(32-46)crates/starknet-devnet-core/src/starknet/events.rs (1)
get_events(21-87)
🔇 Additional comments (5)
crates/starknet-devnet-core/src/starknet/mod.rs (5)
707-756: Significant improvement to error handling in thecallmethod.The error handling in the
callmethod has been enhanced to provide more specific error cases, particularly for entrypoint not found situations. This makes debugging much easier for developers.
856-895: Updated mint function to use V3 transaction format.The mint function has been properly updated to support the new transaction format with resource bounds, tip, and DA mode settings. This is necessary for compatibility with Starknet 0.13.4.
1492-1514: New method for tracking L1 to L2 message status.The
get_messages_statusmethod provides important functionality for tracking cross-layer messages, which is essential for L1<>L2 interoperability. The implementation correctly handles message status and failure reasons.
1292-1313: Updated transaction simulation to include gas vector computation mode.The simulation logic now properly passes the gas vector computation mode to the trace creation, ensuring that simulations accurately reflect the actual execution environment.
482-493:Details
✅ Verification successful
Updated gas price structure to support L2 gas pricing.
The gas price structure has been enhanced to include L2 gas prices for both ETH and STRK tokens, which aligns with Starknet 0.13.4 requirements. This is a significant change that may affect transaction fee calculations.
Check if there are any existing tests that validate gas price calculations that might need updates:
🏁 Script executed:
#!/bin/bash # Search for gas price tests that might need updating rg -A 5 "test.*gas.*price" --type rustLength of output: 3472
Gas Price Structure Verified – Ready for Approval
The integration tests in
tests/integration/test_simulate_transactions.rsandtests/integration/test_gas_modification.rsclearly verify that the new L2 gas pricing fields, for both ETH and STRK tokens, are correctly implemented. The tests include assertions onl2_gas_price(e.g., comparing againstdefault_l2_gas_priceand updates in simulation cases), confirming that our modifications align with Starknet 0.13.4 requirements and correctly affect transaction fee calculations.
- The new L2 gas price fields in both token vectors are properly validated.
- Existing tests already cover these changes, so no additional test updates are required.
| pub fn get_unlimited_events( | ||
| &self, | ||
| from_block: Option<BlockId>, | ||
| to_block: Option<BlockId>, | ||
| address: Option<ContractAddress>, | ||
| keys: Option<Vec<Vec<Felt>>>, | ||
| ) -> DevnetResult<Vec<EmittedEvent>> { | ||
| events::get_events(self, from_block, to_block, address, keys, 0, None) | ||
| .map(|(emitted_events, _)| emitted_events) | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
New utility method for unlimited event retrieval.
The get_unlimited_events method is a helpful addition that simplifies retrieving all events. However, be cautious about potential memory usage for large event sets.
Consider optimizing this method for production use by adding a warning or limit when running in non-development environments:
🏁 Script executed:
#!/bin/bash
# Find usages of get_unlimited_events to verify if there are any safeguards
rg -A 3 "get_unlimited_events" --type rustLength of output: 1620
Action Required: Add Production Safeguards for Unlimited Event Retrieval
The new get_unlimited_events method is a useful addition for retrieving events, but our investigation confirms that it’s already being called in production paths (e.g., in crates/starknet-devnet-server/src/api/json_rpc/endpoints_ws.rs and crates/starknet-devnet-server/src/api/json_rpc/mod.rs). Given its inherently unbounded nature, this could lead to significant memory usage issues when handling large event sets in production.
Recommendations:
- Add environment checks: Introduce a mechanism (such as a configuration flag or environment variable) to conditionally enforce limits or emit warnings in non-development environments.
- Limit retrieval size: Consider applying a limit on the number of events returned or providing a paginated API to manage memory usage effectively.
Snippet Context:
pub fn get_unlimited_events(
&self,
from_block: Option<BlockId>,
to_block: Option<BlockId>,
address: Option<ContractAddress>,
keys: Option<Vec<Vec<Felt>>>,
) -> DevnetResult<Vec<EmittedEvent>> {
events::get_events(self, from_block, to_block, address, keys, 0, None)
.map(|(emitted_events, _)| emitted_events)
}Please address these points to ensure that the unlimited retrieval option does not compromise production stability.
Usage related changes
Development related changes
Waiting for starknet-rs to receive RPC 0.8.0 support. Until then, too many of our tests are failing.Merging and new version release is thus blocked.Basically waiting for this issue to be handled: JSON-RPC v0.8.0 support xJonathanLEI/starknet-rs#674Checklist:
./scripts/format.sh./scripts/clippy_check.sh./scripts/check_unused_deps.sh./scripts/check_spelling.sh./website/README.mdSummary by CodeRabbit
Summary by CodeRabbit
New Features
L1HandlerTransactionwith an optional L1 transaction hash.Improvements
Chores