Skip to content

feat(config): add Qwen3.8 GB300 AgentX / feat(config): 新增 Qwen3.8 GB300 AgentX 配置 - #3816

Merged
cquil11 merged 3 commits into
mainfrom
qwen38next-fp4-gb300-sglang-agentx
Oct 9, 2026
Merged

cquil11 merged 3 commits into
mainfrom
qwen38next-fp4-gb300-sglang-agentx

Conversation

@RohitNagraj

Copy link
Copy Markdown
Collaborator

Add a GB300 AgentX configuration for Qwen3.8-Flash-Next NVFP4 using stock SGLang v0.5.21-cu130, aggregate TP1/EP1, native NEXTN MTP, and SGLang HiCache. Cover concurrency 1, 2, 4, 8, 16, 32, 48, and 64.

Pin the container digest and checkpoint revision, retain the checkpoint's embedded MTP head, and use BF16 target/draft KV. Enable engine metrics and cache reporting, with automatic golden acceptance for throughput and real verification for evaluation. Use the existing GB300 cluster profile and native Hugging Face checkpoint loading.

AI model disclosure

The runtime identifies the GPT-6 family; the exact model/version could not be verified. Role: configuration preparation, review, and local validation. No delegated agents contributed.

PR checklist and change type

Type of Change

  • Bug fix
  • New feature
  • Configuration change
  • Documentation update
  • Other (please describe)

Checklist

  • I have completed the AI model disclosure and kept it current
  • I have tested my changes locally
  • I have updated documentation if necessary
  • For every change that can affect benchmark performance and every recipe addition or modification, I have appended a new entry to the physical end of inferencex-e2e/perf-changelog.yaml and have not edited historical entries
  • If this PR can affect benchmark performance or adds or modifies a recipe, it carries exactly one primary sweep label (a maintainer applies it on fork PRs): full-sweep-fail-fast (recommended), full-sweep-enabled, or non-canary-full-sweep-enabled. Optional modifiers all-evals, evals-only, and agentx-fast require a primary label; the last two block reuse.
  • Before merging via reuse, an authorized maintainer (OWNER/MEMBER/COLLABORATOR) has commented /use <run_id> (or the legacy /reuse-sweep-run) on this PR. Do this only once there is a final full sweep that is all green with evals passing, since after this comment the primary sweep label will no longer automatically kick off new sweeps. Remove and re-add the primary sweep label to force a new sweep.
中文

新增 Qwen3.8-Flash-Next NVFP4 的 GB300 AgentX 配置,使用原版 SGLang v0.5.21-cu130、聚合式 TP1/EP1、原生 NEXTN MTP 和 SGLang HiCache,覆盖并发数 1、2、4、8、16、32、48、64。

固定容器 digest 和 checkpoint 版本,保留 checkpoint 自带的 MTP head,并为 target 和 draft 使用 BF16 KV。启用引擎 metrics 和缓存报告;吞吐测试自动选择 golden acceptance,质量评测使用真实验证。使用现有 GB300 cluster profile 和原生 Hugging Face checkpoint 加载方式。

运行环境仅标识 GPT-6 系列,无法核实准确模型及版本。工作内容为配置准备、审查和本地验证;未使用委派 agent。改动类型为新增功能和配置变更,检查清单已在上方填写。

新增 Qwen3.8-Flash-Next NVFP4 的 GB300 AgentX 配置,使用原生 NEXTN MTP 和 SGLang HiCache。
@github-actions

github-actions Bot commented Oct 8, 2026

Copy link
Copy Markdown
Contributor

Thanks for the contribution!

  • Review: If this PR changes files owned by someone other than a repository admin or @SemiAnalysisAI/core, ask one eligible CODEOWNER to complete the latest PR_REVIEW_CHECKLIST.md before contacting a core maintainer on Slack. Follow the template exactly, including As a PR reviewer and CODEOWNER, I have reviewed this and have, so sign-off verification triggers.
  • PR verification: Sweeps run only when the PR appends an inferencex-e2e/perf-changelog.yaml entry and carries exactly one primary label: full-sweep-fail-fast (strongly recommended; canary plus per-matrix fail-fast), full-sweep-enabled (canary; matrix jobs continue after a failure), or non-canary-full-sweep-enabled (no canary or fail-fast). The modifiers all-evals, evals-only, and agentx-fast require a primary label. On fork PRs, a maintainer applies the label. See sweep labels and reuse.
  • After merging: PR authors must ensure all GitHub Actions jobs pass. Transient failures often pass on rerun; see how to rerun failed jobs.
中文

感谢你的贡献!

  • **审阅:**如果 PR 修改的文件归属于仓库管理员及 @SemiAnalysisAI/core 之外的 CODEOWNER,请先联系一位有资格的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,再通过 Slack 联系核心维护者。必须严格遵循模板,并保留 As a PR reviewer and CODEOWNER, I have reviewed this and have,才能触发签核验证。
  • **PR 验证:**只有当 PR 在 inferencex-e2e/perf-changelog.yaml 末尾追加了条目,并且恰好带有一个主标签时,才会运行扫描:full-sweep-fail-fast(强烈推荐;canary 加逐矩阵 fail-fast)、full-sweep-enabled(有 canary;矩阵任务在失败后继续运行)或 non-canary-full-sweep-enabled(无 canary,也无 fail-fast)。修饰标签 all-evals、evals-only 和 agentx-fast 必须与主标签一起使用。fork PR 的标签由维护者添加。参见扫描标签与复用。
  • **合并后:**PR 作者必须确保所有 GitHub Actions 任务通过。临时性失败通常可以通过重新运行恢复;参见重新运行失败任务的说明。

更新 Qwen3.8 GB300 changelog 条目的 PR 链接。
@RohitNagraj RohitNagraj added the full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures label Oct 8, 2026

@claude claude Bot 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.

I reviewed this PR and didn't find any bugs. Because the two files it touches (inferencex-e2e/configs/nvidia-master.yaml and the new gb300-fp4-mtp/agentic.yaml recipe) are CODEOWNERS-protected and require sign-off from the listed NVIDIA maintainers, a human look would still be worthwhile.

What was reviewed:

  • New agentic.yaml recipe: identity.container.image and model.container match; checked the enable-linear-replayssm-spec without linear-replayssm-cache-len concern raised by earlier passes — several other existing recipes in the repo (e.g. the gb300-fp8 nightly agentx configs) also omit this companion flag, so it's not unique to this change.
  • Confirmed the missing USE_CHAT_TEMPLATE env var is expected here: validate_recipe in infx/srt_slurm/single_node.py only requires it for non-agentic recipes, and this one is agentic (srt_agentic.sh).
  • nvidia-master.yaml's new search-space entry and the perf-changelog.yaml entry are consistent with the recipe and correctly appended at the tail.
  • The changelog's pr-link is still the pull/XXX placeholder; per CONTRIBUTING.md that's filled in after the PR number is known, but it should be set to the real URL before merge.
Extended reasoning...

Config/recipe-only addition (new SGLang GB300 AgentX recipe for Qwen3.8-Flash-Next NVFP4, a master-config entry, and a perf-changelog block) with no source code touched, so no injection/auth/data-exposure surface. Verified the image/container pin matches, the agentic-only USE_CHAT_TEMPLATE exemption in validate_recipe, and that the flagged replayssm cache-len omission has precedent elsewhere in the repo. Both changed files fall under CODEOWNERS entries naming specific NVIDIA maintainers (including the PR author themselves), which is the deciding factor for deferring to a human review rather than approving.

This review covers commit c01e7c4, which is no longer the latest commit on this pull request; later commits are not covered by it.

@github-actions

github-actions Bot commented Oct 8, 2026

Copy link
Copy Markdown
Contributor

@RohitNagraj

Copy link
Copy Markdown
Collaborator Author

/use 37714835620

@github-actions

github-actions Bot commented Oct 8, 2026 •

Copy link
Copy Markdown
Contributor

@RohitNagraj staged run 37714835620: https://inferencemax-app-git-staging-semianalysisai.vercel.app/inference?i_dates=2026-10-08~r37714835620

This run remains available across future /stage-results requests. Staging the same run ID again updates its staged data. Staging workflow

@Ankur-singh

Copy link
Copy Markdown
Collaborator

As a PR reviewer and CODEOWNER, I have reviewed this and have:

  • Verified that as of the moment of typing this, this is the latest version of PR_REVIEW_CHECKLIST.md
  • Verified that the general code quality meets the InferenceX standard and does not make the code quality any worse.
  • Verified that this PR has passed PR validation. Please link to GitHub Action workflow that shows this.
  • Verified that this PR passes evals. Please link to GitHub Action workflow that shows this.
  • Verified that speculative decoding PRs uses chat templates to align the AL distribution to real world
  • Verified that every draft model and draft head is served as it ships: the draft that ships with the served checkpoint, at its stored precision, through the pinned upstream image's default handling, with the shipped and effective draft precision recorded in the additional detail section. No submission-side quantization, dtype override, checkpoint substitution, or patch may lower draft precision below that default, regardless of eval results or AL. Explicitly verified that SGLANG_NVFP4_CKPT_FP8_NEXTN_MOE is not enabled in the effective recipe, including inherited settings; enabling it is prohibited going forward, and historical runs do not grant an exception. See Draft-model precision for what counts as the default and the MLPerf comparison.
  • For agentic workloads: verified that speculative-decoding configs (EAGLE / MTP / draft models) run with simulated synthetic acceptance, with the acceptance-length value taken from the committed golden AL curve in infx/golden_al_distribution/ for that model, thinking mode, and draft length. A submission may choose any supported draft length, but it may not substitute a different acceptance target.
  • Verified against the current MODELS.md that this PR does not submit a deprecated model, scenario, or model-scenario combination.
  • Verified that the model architecture isn't changed with benchmark hacks like using --hf-overrides to skipping indexer for every x layers on models that don't natively support this. As a general rule, we won't accept optimizations that reduces the number of model architecture FLOPs. Anything that makes that same computation run faster is fair game; target/verifier FLOPs at lower precisions is fine, given that the config passes private evals, but this does not permit lowering draft-model or draft-head precision below what ships. As an general north star princple, we should only use optimizations which is used in production by customers that care about accuracy
  • If an company claims that they support vLLM/SGLang as first class LLM inference engines on their hardware, I have verified that the respective vLLM submission made using upstream https://hub.docker.com/u/vllm docker repo, upstream SGLang https://hub.docker.com/u/lmsysorg docker repo. The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet as supported by vLLM/SGLang community maintainers
  • If an company claims that they support vLLM/SGLang as first class upstream in-tree LLM inference engines on their hardware, I have have verified that the respective vLLM/SGLang submission has been made before additional frameworks (TRT-LLM, ATOM, etc.). The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet.
  • Verified that every affected vLLM/SGLang production serving configuration in this PR, including Dynamo deployments, is documented in the official vLLM recipes and/or the SGLang cookbook, for both single-node and multi-node aggregated and disaggregated serving. The documentation covers production-useful flags, environment variables, and launch commands (including prefill, decode, and router/frontend commands for disaggregation); InferenceX-only benchmark/harness settings are excluded with reasoning in the additional detail section:
    • I linked the corresponding upstream PR in the vLLM recipe repo or SGLang cookbook source repo and verified that it is MERGED before this InferenceX PR merges. An opened, draft, or closed-without-merge upstream PR does not satisfy this requirement. If the matching recipe was already published, I linked the published recipe/cookbook page in the additional detail section below.
  • Verified that this PR does not patch the inference engine or serving stack — the pinned image must run as shipped. This covers .patch files / git apply / patch, inline patches embedded in benchmark scripts (e.g. a python3/sed heredoc that rewrites installed engine sources before serving), in-place edits of site-packages, monkey-patching, overwriting container files, and installing forked/rebuilt engine wheels on top of the pinned image. The only exception is a patch covered by a filled-out waiver at docs/waiver/<PR_NUMBER>.md — named after the PR that introduces the patch and filed in that same PR, stating what is patched, why the unmodified upstream image cannot run this benchmark, the upstream PR/issue link, and the removal plan — which I have linked below in the additional detail section.
  • If this PR uses append-only: true, verified that it only adds generated points or recipe variants inside a selected existing config/scenario and existing same-image visual curve: every previously generated point remains present with the same recipe, no prior point is removed or rerun, and every benchmark-affecting change in the complete diff can affect only the corresponding newly appended points (never an existing point), regardless of which file contains it.
  • If any of the above criteria cannot reasonably be satisfied, I have provided additional reasoning below.
  • Reported measured throughput/E2EL Pareto counts and evidence per affected curve (≥5 points strongly recommended). Below 5 or unverifiable: tag a core maintainer for review; recorded admin bypass required before merge. N/A if no curves are affected. Details.

Additional detail section:

  • Assessed head: e67ca6fc9ecf4cd57f27654bda8a3e9059923820. Policy read at main@255b9b89. New config qwen3.8next-fp4-gb300-sglang-agentic-mtp (single-node agg TP1/EP1, agentic-coding).

  • Validation: run 37714835620, attempt 1 ran on the head commit. All 8 agentic / jobs (c1–c64) and the agentic eval / job passed. The authorized /use 37714835620 is already posted.

  • Evals: GSM8K em_strict 97.35% (± 0.44%, n=1319). The eval ran on the same digest-pinned image with real MTP verification; no SGLANG_SIMULATE_ACC_* was set for the eval server.

  • Chat template: the aiperf agentx client uses the chat endpoint (profile_export_aiperf.json: endpoint.type=chat). The server auto-detects the Qwen3 chat template with thinking on by default.

  • Golden AL: infx.srt_slurm.synthetic_acceptance injects the AL automatically from qwen3.8next_mtp.yaml. The config uses thinking_on with speculative-num-steps 3, so the golden AL is 2.32. The runtime environment confirms SGLANG_SIMULATE_ACC_LEN=2.32, match-expected, real-draft-token. The recipe sets no manual AL.

  • Draft precision: the embedded MTP head comes from the same checkpoint (nvidia/Qwen3.8-Flash-Next-NVFP4@fc694b54; draft revision pinned to the same SHA). In the shipped hf_quant_config.json, mtp.layers.0.mlp.experts is FP8_BLOCK_SCALES (128×128). The rest of the MTP head is BF16; per the model card it matches Qwen/Qwen3.8-Flash-Next-FP8 byte-for-byte. The pinned image's default handling is the modelopt_mixed per-layer loader, which the draft inherits; the log shows type=Qwen4ExpForCausalLMMTP, quant=modelopt_mixed, quant_algo=MIXED_PRECISION. Effective draft precision therefore matches what ships (FP8 block-scaled routed experts, BF16 elsewhere). SGLANG_NVFP4_CKPT_FP8_NEXTN_MOE=0 is set explicitly and confirmed in the runtime environment. Target and draft KV are both BF16 (speculative_draft_kv_cache_dtype=bfloat16).

  • Architecture / metrics: no --hf-overrides, json-model-override-args or layer/expert trimming. publish_events_and_metrics is a TRT-LLM setting and does not apply to SGLang; --enable-metrics and --enable-cache-report are on.

  • Image / ordering: lmsysorg/sglang:v0.5.21-cu130@sha256:1f176b3a… is upstream (SGLang build e00930c5). This is an SGLang entry, so engine-first ordering is satisfied (existing qwen3.8next SGLang entries exist on B200/B300/H200).

  • MODELS.md: qwen3.8next is active for Agentic coding (added 2026-08-26), with native/upstream SGLang listed as the primary engine.

  • Recipe: sgl-project/sglang#43159 is MERGED (2026-10-08T23:56Z, 2b94cb4e). It adds the GB300 long-context section and the GB300 → NVFP4 (NVDA) → Low Latency → Single Node builder cell. That cell carries the same digest, both checkpoint revisions, all five serving env vars and every non-default serving flag. 15 flags are omitted because they equal the pinned build's defaults. I checked each one against sgl-project/sglang@e00930c5:

    • TP/PP/DP/EP default to 1.
    • mamba-track-interval defaults to 256 and max-prefill-tokens to 16384.
    • moe-a2a-backend defaults to none and decode CUDA graphs default to full.
    • hicache-io-backend defaults to kernel, hicache-mem-layout to page_first and ple-offload-backend to pinned.
    • tokenizer-worker-num and scheduler-recv-interval default to 1.
    • served-model-name falls back to the model path, and speculative-moe-runner-backend inherits the target's flashinfer_trtllm.

    Excluded as InferenceX-only: the trace dataset (WEKA_LOADER_OVERRIDE), simulated-acceptance env vars, CONC overrides, TOTAL_CPU_DRAM_GB/KV_OFFLOADING binding checks, and Slurm/srun/health-check settings.

  • Engine patches: none. The recipe uses the stock image with no overlay, patch, sed, pip install or waiver.

  • Append-only: N/A. The changelog entry does not set append-only; this is a new config.

  • Pareto (run 37714835620, total tput/GPU vs E2EL): one curve, qwen3.8next / agentic-coding / gb300_sglang / fp4. Counts come from the upstream pareto_coverage.py helper on the bmk_* artifacts.

    • p90 E2EL: 5/5 frontier points (c4, c8, c16, c32, c48). c1, c2 and c64 are dominated.
    • p75 E2EL: 7/5 frontier points.
    • All 8 measured points are valid.
  • Note: the PR currently has a merge conflict with main. Resolve it without dropping e67ca6fc from the PR history, so /use 37714835620 stays valid for reuse.

Signed: Ankur-singh

@github-actions

github-actions Bot commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

✅✅✅ Verdict: PASS ✅✅✅

Passed and not applicable checks

✅ Check 0 (CODEOWNER): PASS — @ankur-singh is a listed owner of inferencex-e2e/configs/nvidia-master.yaml and /inferencex-e2e/benchmarks/*_node/srt-slurm-recipes/**/gb300-*/; perf-changelog.yaml falls under the catch-all only.

✅ Check 1 (Passing sweep + evals on in-PR commit): PASS — head e67ca6fc (in the PR) has 8/8 agentic / jobs (c1–c64) and the agentic eval / job at success in run 37714835620, attempt 1, run headSha = head. This is an agentic-only config, so the fixed-sequence single-node */ and eval / jobs are correctly skipped.

✅ Check 2 (Eval accuracy): PASS — eval_results_all/agg_eval_all.json: GSM8K em_strict 0.9735 ± 0.0044, n=1319, infrastructure_success: true. The eval job ran lmsysorg/sglang:v0.5.21-cu130@sha256:1f176b3a…2384977, the same image as the config.

✅ Check 3 (Upstream recipe): PASS — sgl-project/sglang#43159 is MERGED (2026-10-08T23:56:31Z, 2b94cb4e). Its GB300 / NVFP4 (NVDA) / Low Latency / Single Node cell pins the same digest and both revisions, sets all 5 env vars, and lists every non-default flag. I checked the omitted flags against the defaults at sglang@e00930c5: TP/PP/DP/EP=1, max_prefill_tokens=16384, mamba_track_interval=256, moe_a2a_backend=none, decode graph=FULL, hicache_io_backend=kernel, hicache_mem_layout=page_first, ple_offload_backend=pinned, tokenizer/scheduler=1, and the draft MoE backend falls back to moe.runner_backend. The sign-off justifies the InferenceX-only exclusions.

✅ Check 4 (Reuse command): PASS — /use 37714835620 was posted by RohitNagraj (COLLABORATOR) on 2026-10-08.

✅ Check 5 (Latest checklist template): PASS — all 16 items in the current template, including the recipe sub-item, are present and checked.

✅ Check 6 (Upstream image / engine-first): PASS — framework: sglang uses upstream lmsysorg/sglang:v0.5.21-cu130@sha256:… on GB300. The PR adds only an open-source engine entry.

✅ Check 7 (No deprecated models/scenarios): PASS — MODELS.md lists qwen3.8next as active for Agentic coding (added 2026-08-26, #2742). There is no deprecation notice as of 2026-10-09.

✅ Check 8 (No architecture hacks / event publication): PASS — no --hf-overrides, json-model-override-args, config edits or trimming. publish_events_and_metrics appears only in TRT-LLM recipes in this repo and is not an SGLang setting. --enable-metrics and --enable-cache-report are on.

✅ Check 9 (Spec-decode via chat template): PASS — the aiperf profile_export_aiperf.json for c1 shows endpoint.type: chat with streaming. The eval uses local-chat-completions --apply_chat_template.

✅ Check 10 (No engine patches): PASS — the stock image runs with no patch, sed, overlay, monkey-patch or engine pip install in the recipe or config.

✅ Check 11 (Agentic golden AL): PASS — the c4 job log shows SGLANG_SIMULATE_ACC_LEN=2.32, match-expected and real-draft-token injected at runtime. This equals the qwen3.8next_mtp.yaml value for thinking_on with speculative-num-steps 3, which is 2.32.

➖ Check 12 (Append-only): N/A — the new changelog entry does not set append-only: true.

✅ Check 13 (Draft runs as shipped): PASS — the embedded MTP head comes from the same checkpoint revision fc694b54. In hf_quant_config.json at that revision, only mtp.layers.0.mlp.experts is quantized (FP8_BLOCK_SCALES, group 128) and the rest of the head is unquantized. The runtime loads the draft with the default modelopt_mixed loader. There are no draft quantization or dtype overrides, the draft KV is bf16 (same as the target), and SGLANG_NVFP4_CKPT_FP8_NEXTN_MOE=0 is confirmed in the runtime environment.

✅ Check 14 (Pareto coverage): PASS — one curve, qwen3.8next / agentic-coding / gb300_sglang / fp4, from run 37714835620 attempt 1 (bmk_* artifacts, source SHA e67ca6fc, same image). There are no prior GB300 SGLang qwen3.8next points. Running pareto_coverage.py on total tput/GPU vs E2EL gives p90 = 5/5 frontier points (c4, c8, c16, c32, c48; 8 measured, 0 invalid) and p75 = 7/5.

✅ Check 15 (PR description): PASS — the body's claims match the code and run: stock SGLang v0.5.21-cu130 with a pinned digest and revision, TP1/EP1 aggregate, NEXTN MTP, HiCache, concurrency 1–64, BF16 target/draft KV, metrics and cache reporting, golden AL for throughput and real verification for the eval.

Assessed commit: e67ca6fc9ecf4cd57f27654bda8a3e9059923820.

@functionstackx functionstackx left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

.

@functionstackx
functionstackx self-requested a review October 9, 2026 01:33

@functionstackx functionstackx left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

can u add to cookbook , the new ponah way

@nvpohanh

nvpohanh commented Oct 9, 2026

Copy link
Copy Markdown
Collaborator

[by Claude Code] The SGLang cookbook integration of this PR's AgentX config (qwen3.8next-fp4-gb300-sglang-agentic-mtp) will happen in sgl-project/sglang#43083, in the Agentic Long-Context Deployment section of the Qwen3.8-Flash-Next cookbook page. It mirrors the launch measured in run 37714835620, pinned by this PR's /use comment.

@nvpohanh

nvpohanh commented Oct 9, 2026

Copy link
Copy Markdown
Collaborator

[by Claude Code] sgl-project/sglang#43083 has been merged. This PR's AgentX config (qwen3.8next-fp4-gb300-sglang-agentic-mtp) is now in the Agentic Long-Context Deployment section of the SGLang Qwen3.8-Flash-Next cookbook: https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-Flash-Next#agentic-long-context-deployment

The commands mirror the launch measured in run 37714835620, pinned by this PR's /use comment.

@cquil11 cquil11 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Approved for merge with the existing CODEOWNER sign-off and sweep reuse. The cookbook update is merged in sgl-project/sglang#43083.

@cquil11
cquil11 merged commit daaa107 into main Oct 9, 2026
27 checks passed
@cquil11
cquil11 deleted the qwen38next-fp4-gb300-sglang-agentx branch October 9, 2026 14:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

5 participants