Skip to content

Replace remaining occurrences of pending with pre-confirmed#811

Merged
FabijanC merged 1 commit intomainfrom
pending-leftover
Jul 17, 2025
Merged

Replace remaining occurrences of pending with pre-confirmed#811
FabijanC merged 1 commit intomainfrom
pending-leftover

Conversation

@FabijanC
Copy link
Copy Markdown
Contributor

@FabijanC FabijanC commented Jul 17, 2025

Usage related changes

N/A

Development related changes

Checklist:

  • Checked out the contribution guidelines
  • Applied formatting - ./scripts/format.sh
  • No linter errors - ./scripts/clippy_check.sh
  • No unused dependencies - ./scripts/check_unused_deps.sh
  • No spelling errors - ./scripts/check_spelling.sh
  • Performed code self-review
  • Rebased to the latest commit of the target branch (or merged it into my branch)
    • Once you make the PR reviewable, please avoid force-pushing
  • Updated the docs if needed - ./website/README.md
  • Linked the issues resolvable by this PR - linking info
  • Updated the tests if needed; all passing - execution info

Summary by CodeRabbit

  • Refactor

    • Updated terminology throughout the application from "pending" to "pre-confirmed" for block tags, methods, variables, and documentation.
    • Renamed public methods and updated references in tests and comments to reflect the new "pre-confirmed" terminology.
  • Documentation

    • Revised comments and error messages to use "pre-confirmed" instead of "pending" for improved clarity and consistency.

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Jul 17, 2025

Walkthrough

This change updates the terminology throughout the codebase and tests, replacing references to "pending" blocks and transactions with "pre-confirmed." The updates include renaming methods, variables, and function signatures, as well as modifying comments and documentation to use "pre-confirmed" instead of "pending." These changes affect both the core and server modules, as well as integration tests and helper functions. No functional or logic changes are introduced; the modifications are limited to aligning the code and documentation with the updated terminology.

Possibly related PRs

  • Test case: set time when pre-confirmed txs #806: Updates terminology from "pending" to "pre-confirmed" in test calls and comments, including in test_advancing_time.rs, directly relating to the changes in this PR.
  • Update to Starknet 0.14 #802: Performs a comprehensive renaming and refactoring in starknet-devnet-core/src/blocks/mod.rs and related logic, replacing "pending" with "pre_confirmed" at the code level, which is closely related to the updates in this PR.

📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 464ffa5 and 315bb4b.

📒 Files selected for processing (11)
  • crates/starknet-devnet-core/src/blocks/mod.rs (4 hunks)
  • crates/starknet-devnet-server/src/api/json_rpc/endpoints_ws.rs (4 hunks)
  • crates/starknet-devnet-server/src/api/json_rpc/mod.rs (2 hunks)
  • crates/starknet-devnet-server/src/api/json_rpc/origin_forwarder.rs (1 hunks)
  • crates/starknet-devnet-types/src/rpc/block.rs (1 hunks)
  • tests/integration/common/background_devnet.rs (3 hunks)
  • tests/integration/test_accepting_blocks_on_l1.rs (1 hunks)
  • tests/integration/test_advancing_time.rs (3 hunks)
  • tests/integration/test_blocks_generation.rs (2 hunks)
  • tests/integration/test_gas_modification.rs (3 hunks)
  • tests/integration/test_simulate_transactions.rs (1 hunks)
🧰 Additional context used
🧠 Learnings (10)
📓 Common learnings
Learnt from: FabijanC
PR: 0xSpaceShard/starknet-devnet#755
File: crates/starknet-devnet-server/test_data/spec/0.8.1/starknet_executables.json:1154-1168
Timestamp: 2025-04-14T09:33:59.391Z
Learning: FabijanC wants to configure CodeRabbit to ignore spec files from review, specifically the JSON schema files in the test_data/spec directory.
crates/starknet-devnet-types/src/rpc/block.rs (1)
Learnt from: FabijanC
PR: 0xSpaceShard/starknet-devnet#799
File: crates/starknet-devnet-core/src/starknet/mod.rs:240-246
Timestamp: 2025-06-16T07:35:24.725Z
Learning: In the Starknet devnet codebase, `get_class_hash_at` has different behaviors at different layers: at the internal state level (blockifier), it returns `Ok(ClassHash(Felt::ZERO))` for undeployed addresses, while at the RPC layer, this gets converted to `Err(Error::ContractNotFound)`. When checking if a contract is deployed at the internal state level, use `is_ok_and(|h| h.0 == Felt::ZERO)` to detect undeployed addresses.
tests/integration/test_accepting_blocks_on_l1.rs (1)
Learnt from: FabijanC
PR: 0xSpaceShard/starknet-devnet#799
File: crates/starknet-devnet-core/src/starknet/mod.rs:240-246
Timestamp: 2025-06-16T07:35:24.725Z
Learning: In the Starknet devnet codebase, `get_class_hash_at` has different behaviors at different layers: at the internal state level (blockifier), it returns `Ok(ClassHash(Felt::ZERO))` for undeployed addresses, while at the RPC layer, this gets converted to `Err(Error::ContractNotFound)`. When checking if a contract is deployed at the internal state level, use `is_ok_and(|h| h.0 == Felt::ZERO)` to detect undeployed addresses.
tests/integration/test_blocks_generation.rs (1)
Learnt from: FabijanC
PR: 0xSpaceShard/starknet-devnet#799
File: crates/starknet-devnet-core/src/starknet/mod.rs:240-246
Timestamp: 2025-06-16T07:35:24.725Z
Learning: In the Starknet devnet codebase, `get_class_hash_at` has different behaviors at different layers: at the internal state level (blockifier), it returns `Ok(ClassHash(Felt::ZERO))` for undeployed addresses, while at the RPC layer, this gets converted to `Err(Error::ContractNotFound)`. When checking if a contract is deployed at the internal state level, use `is_ok_and(|h| h.0 == Felt::ZERO)` to detect undeployed addresses.
tests/integration/test_gas_modification.rs (1)
Learnt from: FabijanC
PR: 0xSpaceShard/starknet-devnet#799
File: crates/starknet-devnet-core/src/starknet/mod.rs:240-246
Timestamp: 2025-06-16T07:35:24.725Z
Learning: In the Starknet devnet codebase, `get_class_hash_at` has different behaviors at different layers: at the internal state level (blockifier), it returns `Ok(ClassHash(Felt::ZERO))` for undeployed addresses, while at the RPC layer, this gets converted to `Err(Error::ContractNotFound)`. When checking if a contract is deployed at the internal state level, use `is_ok_and(|h| h.0 == Felt::ZERO)` to detect undeployed addresses.
crates/starknet-devnet-server/src/api/json_rpc/origin_forwarder.rs (1)
Learnt from: FabijanC
PR: 0xSpaceShard/starknet-devnet#799
File: crates/starknet-devnet-core/src/starknet/mod.rs:240-246
Timestamp: 2025-06-16T07:35:24.725Z
Learning: In the Starknet devnet codebase, `get_class_hash_at` has different behaviors at different layers: at the internal state level (blockifier), it returns `Ok(ClassHash(Felt::ZERO))` for undeployed addresses, while at the RPC layer, this gets converted to `Err(Error::ContractNotFound)`. When checking if a contract is deployed at the internal state level, use `is_ok_and(|h| h.0 == Felt::ZERO)` to detect undeployed addresses.
crates/starknet-devnet-server/src/api/json_rpc/mod.rs (1)
Learnt from: FabijanC
PR: 0xSpaceShard/starknet-devnet#799
File: crates/starknet-devnet-core/src/starknet/mod.rs:240-246
Timestamp: 2025-06-16T07:35:24.725Z
Learning: In the Starknet devnet codebase, `get_class_hash_at` has different behaviors at different layers: at the internal state level (blockifier), it returns `Ok(ClassHash(Felt::ZERO))` for undeployed addresses, while at the RPC layer, this gets converted to `Err(Error::ContractNotFound)`. When checking if a contract is deployed at the internal state level, use `is_ok_and(|h| h.0 == Felt::ZERO)` to detect undeployed addresses.
crates/starknet-devnet-core/src/blocks/mod.rs (1)
Learnt from: FabijanC
PR: 0xSpaceShard/starknet-devnet#799
File: crates/starknet-devnet-core/src/starknet/mod.rs:240-246
Timestamp: 2025-06-16T07:35:24.725Z
Learning: In the Starknet devnet codebase, `get_class_hash_at` has different behaviors at different layers: at the internal state level (blockifier), it returns `Ok(ClassHash(Felt::ZERO))` for undeployed addresses, while at the RPC layer, this gets converted to `Err(Error::ContractNotFound)`. When checking if a contract is deployed at the internal state level, use `is_ok_and(|h| h.0 == Felt::ZERO)` to detect undeployed addresses.
crates/starknet-devnet-server/src/api/json_rpc/endpoints_ws.rs (1)
Learnt from: FabijanC
PR: 0xSpaceShard/starknet-devnet#799
File: crates/starknet-devnet-core/src/starknet/mod.rs:240-246
Timestamp: 2025-06-16T07:35:24.725Z
Learning: In the Starknet devnet codebase, `get_class_hash_at` has different behaviors at different layers: at the internal state level (blockifier), it returns `Ok(ClassHash(Felt::ZERO))` for undeployed addresses, while at the RPC layer, this gets converted to `Err(Error::ContractNotFound)`. When checking if a contract is deployed at the internal state level, use `is_ok_and(|h| h.0 == Felt::ZERO)` to detect undeployed addresses.
tests/integration/common/background_devnet.rs (1)
Learnt from: FabijanC
PR: 0xSpaceShard/starknet-devnet#799
File: crates/starknet-devnet-core/src/starknet/mod.rs:240-246
Timestamp: 2025-06-16T07:35:24.725Z
Learning: In the Starknet devnet codebase, `get_class_hash_at` has different behaviors at different layers: at the internal state level (blockifier), it returns `Ok(ClassHash(Felt::ZERO))` for undeployed addresses, while at the RPC layer, this gets converted to `Err(Error::ContractNotFound)`. When checking if a contract is deployed at the internal state level, use `is_ok_and(|h| h.0 == Felt::ZERO)` to detect undeployed addresses.
🧬 Code Graph Analysis (1)
tests/integration/test_advancing_time.rs (2)
crates/starknet-devnet-core/src/starknet/mod.rs (2)
  • pre_confirmed_block (575-577)
  • block (1096-1105)
crates/starknet-devnet-core/src/blocks/mod.rs (1)
  • timestamp (347-349)
🔇 Additional comments (27)
crates/starknet-devnet-types/src/rpc/block.rs (1)

71-71: LGTM: Documentation comment correctly updated.

The comment now accurately reflects that the PreConfirmed variant is "Almost like pre-confirmed" rather than "Almost like pending", which aligns with the variant name and the broader terminology update.

tests/integration/test_accepting_blocks_on_l1.rs (1)

191-191: LGTM: Method call correctly updated to use new naming convention.

The method call has been properly updated from get_pending_block_with_tx_hashes() to get_pre_confirmed_block_with_tx_hashes(), aligning with the broader terminology change from "pending" to "pre-confirmed".

tests/integration/test_simulate_transactions.rs (1)

464-465: LGTM: Variable name updated for better consistency.

The variable name has been correctly updated from pending to pre_confirmed in the match arm for MaybePreConfirmedBlockWithTxHashes::PreConfirmedBlock, making the code more readable and consistent with the enum variant being matched.

crates/starknet-devnet-server/src/api/json_rpc/origin_forwarder.rs (1)

104-105: LGTM: Error message accurately updated.

The error message has been correctly updated from "pending block" to "pre-confirmed block" to accurately reflect the PreConfirmedBlock variant being handled in the match arm. This improves error message accuracy and consistency with the codebase terminology.

crates/starknet-devnet-core/src/blocks/mod.rs (4)

480-480: LGTM: Test comment correctly updated.

The comment has been properly updated from "pending block" to "pre-confirmed block" to align with the new terminology used throughout the codebase.


577-577: LGTM: Test comment correctly updated.

The comment has been properly updated from "latest/pending" to "latest/pre-confirmed" to reflect the current block tag terminology.


600-600: LGTM: Test comment correctly updated.

The comment has been properly updated from "latest/pending" to "latest/pre-confirmed" to maintain consistency with the updated block tag terminology.


646-646: LGTM: Test comment correctly updated.

The comment has been properly updated from "latest/pre-confirmed" to maintain consistency with the updated block tag terminology throughout the test suite.

tests/integration/test_blocks_generation.rs (2)

62-62: Method call updated correctly for terminology consistency.

The change from get_pending_block_with_tx_hashes() to get_pre_confirmed_block_with_tx_hashes() aligns with the PR objective to replace "pending" terminology with "pre-confirmed" throughout the codebase.


88-88: Method call updated correctly for terminology consistency.

The change from get_pending_block_with_txs() to get_pre_confirmed_block_with_txs() is consistent with the broader terminology update from "pending" to "pre-confirmed".

tests/integration/test_advancing_time.rs (4)

326-326: Method call updated correctly for terminology consistency.

The change from get_pending_block_with_tx_hashes() to get_pre_confirmed_block_with_tx_hashes() aligns with the PR objective to replace "pending" terminology with "pre-confirmed" throughout the codebase.


577-577: Method call updated correctly for terminology consistency.

The change from get_pending_block_with_txs() to get_pre_confirmed_block_with_txs() is consistent with the broader terminology update from "pending" to "pre-confirmed".


589-589: Method call updated correctly for terminology consistency.

The change from get_pending_block_with_txs() to get_pre_confirmed_block_with_txs() is consistent with the broader terminology update from "pending" to "pre-confirmed".


595-595: Method call updated correctly for terminology consistency.

The change from get_pending_block_with_txs() to get_pre_confirmed_block_with_txs() is consistent with the broader terminology update from "pending" to "pre-confirmed".

tests/integration/test_gas_modification.rs (4)

289-289: Method call updated correctly for terminology consistency.

The change from get_pending_block_with_tx_hashes() to get_pre_confirmed_block_with_tx_hashes() aligns with the PR objective to replace "pending" terminology with "pre-confirmed" throughout the codebase.


295-295: Method call updated correctly for terminology consistency.

The change from get_pending_block_with_tx_hashes() to get_pre_confirmed_block_with_tx_hashes() is consistent with the broader terminology update from "pending" to "pre-confirmed".


330-330: Method call updated correctly for terminology consistency.

The change from get_pending_block_with_tx_hashes() to get_pre_confirmed_block_with_tx_hashes() is consistent with the broader terminology update from "pending" to "pre-confirmed".


378-378: Method call updated correctly for terminology consistency.

The change from get_pending_block_with_tx_hashes() to get_pre_confirmed_block_with_tx_hashes() is consistent with the broader terminology update from "pending" to "pre-confirmed".

crates/starknet-devnet-server/src/api/json_rpc/mod.rs (2)

327-331: Comment updates improve clarity and consistency.

The updated comments accurately reflect the terminology change from "pending" to "pre-confirmed" and help clarify the notification behavior for transactions in different block states.


342-344: Comment updates align with terminology changes.

The updated comments correctly describe the conditional logic for pre-confirmed block usage and notification behavior.

crates/starknet-devnet-server/src/api/json_rpc/endpoints_ws.rs (4)

56-60: Comment update correctly reflects terminology change.

The updated comment accurately describes the conversion from pre-confirmed to latest block tag.


113-118: Comments consistently updated with new terminology.

The updated comments properly reflect the use of "pre-confirmed" terminology in block ID handling logic.


133-148: Function rename maintains consistency with terminology change.

The function name change from get_pending_txs to get_pre_confirmed_txs aligns with the PR objective while maintaining the same functionality.


178-181: Variable names and comments updated consistently.

The changes from "pending" to "pre-confirmed" in variable names and comments maintain consistency with the overall terminology update.

tests/integration/common/background_devnet.rs (3)

283-283: Comment update reflects terminology change accurately.

The updated comment correctly describes the method's behavior with "pre-confirmed state" terminology.


368-379: Method rename maintains consistency with terminology change.

The method name change from get_pending_block_with_tx_hashes to get_pre_confirmed_block_with_tx_hashes aligns with the PR objective while preserving the same functionality.


388-395: Method rename maintains consistency with terminology change.

The method name change from get_pending_block_with_txs to get_pre_confirmed_block_with_txs aligns with the PR objective while preserving the same functionality.

✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@FabijanC
Copy link
Copy Markdown
Contributor Author

@coderabbitai review

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Jul 17, 2025

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@FabijanC FabijanC merged commit 14ce827 into main Jul 17, 2025
2 checks passed
@FabijanC FabijanC deleted the pending-leftover branch July 17, 2025 11:03
@coderabbitai coderabbitai bot mentioned this pull request Sep 5, 2025
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant