test the GB300 cluster after the node patch by richardhuo-nv · Pull Request #1961 · SemiAnalysisAI/InferenceX

richardhuo-nv · 2026-06-30T19:15:38Z

No description provided.

claude

Additional findings (outside current diff — PR may have been updated during review):

🔴 perf-changelog.yaml:4327-4331 — The new perf-changelog.yaml entry at line 4331 has pr-link: TODO instead of a real URL. The repo's own validator (utils/validate_perf_changelog.py) will reject this — TODO is neither the canonical https://github.com/SemiAnalysisAI/InferenceX/pull/<n> URL nor one of the allowed XXX placeholders, so changelog CI will fail until this is replaced with https://github.com/SemiAnalysisAI/InferenceX/pull/1961 (or one of the documented XXX placeholders).
Extended reasoning...

What the bug is

The new entry added at perf-changelog.yaml:4327-4331 ends with:
```
  pr-link: TODO
```
Every other entry in this 541-entry file uses a real GitHub URL of the form https://github.com/SemiAnalysisAI/InferenceX/pull/<n> (e.g., the immediately preceding entry at line 4325 uses https://github.com/SemiAnalysisAI/InferenceX/pull/1954). The literal string TODO is unique to this PR.

Why this is more than cosmetic — it fails the repo's validator

This is not just a stale-placeholder concern. The repo ships utils/validate_perf_changelog.py, which has strict rules:
```
CANONICAL_PR_LINK = re.compile(
    r"https://github\.com/SemiAnalysisAI/InferenceX/pull/\d+"
)
PR_LINK_PLACEHOLDERS = {
    "XXX",
    "https://github.com/SemiAnalysisAI/InferenceX/pull/XXX",
}
```
And validate_added_pr_link() (line 144):
```
def validate_added_pr_link(link: str, pr_number: int | None) -> None:
    if pr_number is None:
        if not CANONICAL_PR_LINK.fullmatch(link):
            raise ChangelogValidationError(
                f"new main-branch entry has invalid pr-link: {link!r}"
            )
        return
    expected = f"https://github.com/SemiAnalysisAI/InferenceX/pull/{pr_number}"
    if link not in PR_LINK_PLACEHOLDERS and link != expected:
        raise ChangelogValidationError(
            f"new PR entry must use {expected!r} or an XXX placeholder; "
            f"found {link!r}"
        )
```
Step-by-step proof
1. The PR-run path takes pr_number=1961, sets expected = 'https://github.com/SemiAnalysisAI/InferenceX/pull/1961', then checks 'TODO' not in {'XXX', 'https://github.com/SemiAnalysisAI/InferenceX/pull/XXX'} and 'TODO' != expected. Both conditions are true → ChangelogValidationError: new PR entry must use 'https://github.com/SemiAnalysisAI/InferenceX/pull/1961' or an XXX placeholder; found 'TODO'.
2. The main-branch path (pr_number=None) calls CANONICAL_PR_LINK.fullmatch('TODO') which returns None → ChangelogValidationError: new main-branch entry has invalid pr-link: 'TODO'.
So the entry will either block CI now or, if it somehow lands on main, leave an invalid pr-link permanently. Worse, the same validator's compare_entries() treats entries as immutable except for pr-link-only corrections, so a follow-up fix is the only remediation path.

Impact
- Changelog CI fails until the placeholder is replaced.
- Any downstream tooling that parses pr-link as a URL would break on the literal TODO.
Fix

Replace pr-link: TODO with pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1961 (this PR's number), or with one of the documented XXX placeholders if the URL is genuinely not yet known.

github-actions · 2026-06-30T19:42:49Z

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers.

If additional help is needed, PR authors can reach out to core maintainers over Slack.

感谢你的贡献！对于 vLLM 与 SGLang，请确保你的 recipe 与官方 vLLM recipes 和/或 SGLang cookbook 保持一致

如果不一致，请先创建一个 PR，之后我们才能将你的单节点 PR 合并到 master 分支。让我们确保文档保持一流水准，使整个 ML 社区都能从你的辛勤工作中受益！谢谢

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动（flake），重新运行失败的任务即可解决。如果选择重新运行失败的任务，PR 作者有责任确保其最终通过。参见 GitHub 关于重新运行失败任务的文档：https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

一般而言，PR 作者应先向相应公司的 CODEOWNERS 请求审阅并获得 PR 批准，然后再请求核心维护者审阅。

如需更多帮助，PR 作者可通过 Slack 联系核心维护者。

github-actions · 2026-06-30T19:42:49Z