Skip to content

Remove admission queue bypass mode - #27149

Merged
alex-mysten merged 1 commit into
mainfrom
alex-mysten/refactor-admission-queue
Jul 10, 2026
Merged

Remove admission queue bypass mode#27149
alex-mysten merged 1 commit into
mainfrom
alex-mysten/refactor-admission-queue

Conversation

@alex-mysten

@alex-mysten alex-mysten commented Jul 6, 2026

Copy link
Copy Markdown
Contributor

Description

Follow-up to the sui_mainnet_high_traffic incidents (CORE-198). Bypass let a transaction skip the gas-price priority queue whenever consensus inflight was below a threshold, so admission prioritization and load-shedding were bypassed for effectively all steady-state traffic — and during the transient where inflight dipped, a low-gas transaction could jump straight to consensus ahead of higher-gas entries still waiting in the queue. Remove bypass entirely so all user transactions are admitted through the queue. The only remaining direct-to-consensus paths are: queue turned off by config, failover (queue actor stalled), and ping requests.

Test plan

Covered by the existing admission queue e2e tests in sui-e2e-tests/tests/admission_queue_tests.rs (admission, eviction, rejection, reconfig), which previously forced queue mode via bypass_fraction: 0.0 and now exercise the only behavior.


Release notes

  • Nodes (Validators and Full nodes): Removes the admission-queue-bypass-fraction validator config field; all transactions are now admitted through the gas-price priority queue. The removed field is ignored if still present in a config file, but should be deleted.

@alex-mysten
alex-mysten temporarily deployed to sui-typescript-aws-kms-test-env July 6, 2026 17:32 — with GitHub Actions Inactive
@vercel

vercel Bot commented Jul 6, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
sui-docs Ready Ready Preview, Comment Jul 10, 2026 2:54pm
2 Skipped Deployments
Project Deployment Actions Updated (UTC)
multisig-toolkit Ignored Ignored Preview Jul 10, 2026 2:54pm
sui-kiosk Ignored Ignored Preview Jul 10, 2026 2:54pm

Request Review

@alex-mysten
alex-mysten requested review from a team and mystenmark July 6, 2026 17:33
@alex-mysten
alex-mysten marked this pull request as ready for review July 6, 2026 17:34
@alex-mysten
alex-mysten temporarily deployed to sui-typescript-aws-kms-test-env July 6, 2026 17:34 — with GitHub Actions Inactive
@alex-mysten
alex-mysten force-pushed the alex-mysten/refactor-admission-queue branch from abf0a5b to 0b5a9bf Compare July 7, 2026 18:39
@alex-mysten
alex-mysten temporarily deployed to sui-typescript-aws-kms-test-env July 7, 2026 18:39 — with GitHub Actions Inactive
@alex-mysten alex-mysten changed the title Lower admission queue bypass fraction to 0.1 and failover timeout to 10s Remove admission queue bypass mode and lower failover timeout to 10s Jul 7, 2026

@akichidis akichidis left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Changes make sense. Left a comment regarding the choice of 10 seconds timeout. It might not offer as is - to my understanding - the protection we need during a regression.

Comment thread crates/sui-config/src/node.rs Outdated

fn default_admission_queue_failover_timeout() -> Duration {
Duration::from_secs(30)
Duration::from_secs(10)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

My understanding is that the queue will get tripped now quicker in case of a stall right? For example, if consensus deals with some temporary regression and queue doesn't move within 10 seconds, then it's possible to start seeing low value transactions coming through as they'll bypass it? Isn't this a point where we actually need to be more aggressive on prioritising high value transactions ?

@alex-mysten alex-mysten Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Correct. If we don't drain a tx in 10s, we would fail over to direct submission. I lowered this as a safeguard in case we don't entirely trust the queue implementation, given that our risk of a stall now impacts 100% of transactions. Now I'm thinking we leave failover at 30s for the reasons you've stated.

#27202 changes failover detection logic to "if consensus has capacity, AND we haven't drained in a time period" which perhaps is a little bit more indicative of a real halt with the queue implementation. It could be argued at that point that failover adds complexity during an incident without buying us meaningful safety.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Failover timeout raised back to 30s (the current value)

@alex-mysten
alex-mysten force-pushed the alex-mysten/refactor-admission-queue branch from 0b5a9bf to cc7cb85 Compare July 10, 2026 14:51
@alex-mysten
alex-mysten temporarily deployed to sui-typescript-aws-kms-test-env July 10, 2026 14:51 — with GitHub Actions Inactive
@alex-mysten alex-mysten changed the title Remove admission queue bypass mode and lower failover timeout to 10s Remove admission queue bypass mode Jul 10, 2026
@alex-mysten
alex-mysten merged commit d5b3e23 into main Jul 10, 2026
64 of 66 checks passed
@alex-mysten
alex-mysten deleted the alex-mysten/refactor-admission-queue branch July 10, 2026 18:39
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.

2 participants