Checking mergability - #5
Closed
heemankv wants to merge 1037 commits into
Closed
Conversation
…-max-l2-limit-fix fix(executor): correct max L2 limit in L2 gas estimation logic
…ansaction-status fix(rpc): PreConfirmed transaction status
Both the empty state update we're constructing and the pre-committed state update needs to have the parent state commitment field set to the state commitment of the parent block. This is especially important for the pre-committed state update, as the parent state commitment there is the _only_ way to identify which parent block the state update is for (the block number is not included in the response for `starknet_getStateUpdate`).
Consensus: add write-ahead log (WAL) support
…tManager::cancel_timeout`, add tests
…-timeout-mgr Consensus: Add `ResetTimeouts` effect handling
… data And make sure we return the INVALID_TRANSACTION_NONCE error in case the gateway is returning an invalid nonce error. This is slightly complicated by the fact that the gateway is returning a "validation failure" error instead of the "invalid nonce" error, so the only way for us to detect this is to check the error message for the presence of the "invalid nonce" string.
…-attestation-link chore(docs): add link to validator attestation tool
…ssages-status fix(rpc): get_messages_status returning execution_status for v09
…ix-pre-committed-state-update-parent-state-commitment fix(rpc/pending): properly set parent state commitment in state update
…nvalid-transaction-nonce-error feat(rpc/v09): update INVALID_TRANSACTION_NONCE error with additional data
…d-block fix: download block reorg handling
…athfinder_getTransactionStatus
…der-rpc-api feat(rpc): remove obsolete pathfinder_* APIs
… without execution status For JSON-RPC 0.9.0 we should never return transactions without an execution status, since `execution_status` is a required field in the response.
…tionReceipt` On JSON-RPC 0.9, we have to use `ACCEPTED_ON_L2` if the transaction receipt was found in the pending block, and `PRE_CONFIRMED` if it was in the pre-confirmed block.
…ransaction-status feat(rpc/v09): implement PRE_CONFIRMED and CANDIDATE transaction statuses
We treat it as a synonym for "pending" right now: the internal representation is BlockId::Pending, because that's what our code handles. Semantic differences between "pre_confirmed" and "pending" are already handled based on the actual type of the pending data we have.
…lock The expected behavior is to return an empty pending block for pre-0.9 JSON-RPC versions.
Pre-0.9 JSON-RPC versions require `PendingWatcher::get()` to return an empty _pending_ block instead of an empty _pre-confirmed_ block in case we _do_ have a pre-confirmed block.
The expected behavior is to return an empty pending block for pre-0.9 JSON-RPC versions.
…ther crates don't have to
…lace them with fixed channels in the future
…idation feat: integrate consensus p2p with the consensus engine
…events-finality feat(rpc): starknet_subscribeEvents accepts & returns finality
…be-tx-status-follow-up fix(rpc): subscribe tx status follow-up
…onrpc-0.9.0-spec chore(spec): update JSON-RPC spec to 0.9.0 final
When processing a query with a block range that involves empty blocks (blocks with zero transactions / events) `starknet_getEvents` would stop scanning at the first empty block. This is bad, because it doesn't even return a continuation token so users would have no way of knowing that there are more events. The issue is that `query_events_by_block()` is returning an `Option`, and `None` is being interpreted as "no block found", which causes the scan to stop prematurely when encountering empty blocks. To fix this, we need to ensure that we handle no events correctly in `events_for_block()` and just return an empty vector of events instead of returning `None`.
Ever since we've added `rust-toolchain.toml` to the repository, Docker builds do re-download the toolchain even though we should just be using the one already installed in the image. This commit updates the Dockerfile to exclude the `rust-toolchain.toml` file from the build context, so that the toolchain is not reinstalled.
…nt-reinstall-rust-toolchain fix(docker): don't reinstall Rust toolchain
…s-fix-for-empty-blocks fix(rpc/method/get_events): fix `starknet_getEvents` for empty blocks
Otherwise we just get a parse error from Docker BuildKit.
…e-add-version chore(Dockerfile): add version to dockerfile
chore: bump version to 0.19.0
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Short description of what this PR does.
A longer description, include motivation and intent if possible. Detail any caveats or follow-up steps still required.
Consider motivating any new dependencies.
Delete once completed:
CHANGELOG.md