fix: use REPO_TOKEN by zhyncs · Pull Request #755 · sgl-project/sglang

zhyncs · 2024-07-26T19:55:10Z

Thank you for your contribution, we really appreciate it. The following instructions will help improve your pull request and make it easier to receive feedback. If there are any items you don't understand, don't worry. Just submit the pull request and ask the maintainers for help.

Motivation

Please explain the motivation behind this PR and the goal you aim to achieve with it.

Modification

Briefly describe the changes made in this PR.

Checklist

Ensure pre-commit pre-commit run --all-files or other linting tools are used to fix potential lint issues.
Confirm that modifications are covered by complete unit tests. If not, please add more unit tests for correctness.
Modify documentation as needed, such as docstrings or example tutorials.

fix 0611

…ce in one harvest plan, with a proven runner Consolidated from the comp4 gate run (progress.662-F4-r5), WINDOW_TICKET_745/755, NOTE_747 par.8-9, NOTE_738/755, TICKET_727 and the operator ledger. Two hard incompatibilities shape the plan: WINDOW_TICKET_745 Arm 1 excludes the checkpoint interval that sgl-project#758's anchor-cadence observable requires (-> ARM I hicache harvest, ARM II = one flag more), and sgl-project#713's TTFT<3s needs a quiet router while every other loaded gate needs the soak backlog (-> sgl-project#713 is the idle sub-phase BEFORE the backlog, not a separate boot; the 06:44Z soak driver is the load source per the Lastprobe rule). ARM I phases: load-time (sgl-project#738 no-99G-plateau, file-backed-image reclaim), idle-quiet (sgl-project#713, health, corridor), loaded (Gates A/B/C, - sgl-project#757 race-holds, sgl-project#748 all three shapes, sgl-project#744/sgl-project#717 rung-funded flip, - sgl-project#690 refill census, sgl-project#758-2 mamba host resume, WT_745's three lines, corridor minima), teardown (image reclaim). ARM II adds --mamba-checkpoint-interval 8192 for sgl-project#758-1 anchor cadence + NOTE_747 par.8.1-8.3. SEPARATE windows named with reasons: sgl-project#727 four-boot A/B, WT_755 slots A/B (pool-geometry confound), sgl-project#755 metal retraction (mechanism not built -- nothing to measure), sgl-project#709, sgl-project#735 Step-2. sgl-project#602 and sgl-project#536/sgl-project#537 carried as HONEST unresolved slots (owner-held detail / not found with acceptance shape) rather than invented readouts. Runner run_window_ladder.sh: PASS/FAIL/UNOBS table from boot log + live server; never boots, never kills, never touches the soak driver; soak-tolerant by construction (loaded checks are log observations, the one latency check runs only in --phase idle, and choosing that phase IS the operator's quiet-router assertion). Missing-emitter cases (anchor cadence) report UNOBS, never FAIL -- absence of an instrument is not absence of the property. Mock-smoked per the desk rule, both directions: a fixture built from the comp4 specimen lines reproduces the real run's verdicts exactly (GATE-C crash, both sgl-project#748 shapes + vacuous relief, sgl-project#757 sentence = 5 FAIL; sgl-project#744/sgl-project#690 PASS; exit 1) and a clean fixture goes fully green incl. the ARM II cadence line (exit 0). bash -n clean, codespell clean. Nothing was booted.

…ost copy that was still in flight SERVING RETURNED WRONG ANSWERS. On the full-feature boot, 9 of 10 SALTED greedy "The capital of France is" probes came back degenerate -- ' France is France is France is', and one that echoed the salt hex back. Salted means every probe was a fresh prefix, so this was never a cache-key problem; the same prompt also answered correctly on the 3rd attempt at temperature 0, which is what an anchor that is intermittently missing looks like from outside. Bisecting on the two-curl reproducer put it squarely on the sgl-project#755 reorder: 9/10 degenerate with SGLANG_MAMBA_SLOT_REORDER=1, 1/10 with it 0. THE PREDICATE BELIEVED AN INTENTION. `_mamba_early_release_admissible` asks two questions and the second is `mamba_backuped`, which reads `mamba_host_value is not None`. The write-through path publishes that value in the SAME block that hands the transfer to the cache controller and then records the node in `ongoing_write_through` / `_write_through_inflight` (hi_mamba_radix_cache.py:412-432). So between queue and ack the anchor exists as an intention only, `mamba_backuped` reads True, sgl-project#755 releases the pin, and the node is evictable before its bytes have landed. Evict there and the anchor is dead -- which is the exact failure the predicate exists to prevent, and its own docstring already promised "host-backed RIGHT NOW". Two silent symptoms confirmed it rather than contradicted it: ZERO sgl-project#755 refusals were logged (every node claimed to be backed) while there were ZERO completed backup markers, and a deliberate prefix repeat reported cached=None. A contract that never refuses and never completes is not a contract that is being met. THE FIX IS THE MISSING HALF OF THE QUESTION, not a disabled feature. The predicate now also requires the copy to have LANDED, via an overridable `_mamba_host_copy_complete`: True on the device-only pool, which has no async write-through, and on the hierarchical pool a read of the in-flight bookkeeping the write path already maintains. A node still in flight takes the documented sgl-project#755 refusal path -- insert skipped, request keeps computing, counter says write-through is behind -- instead of trading correctness for a slot. Red-first: the three in-flight tests fail against the old predicate, and the can-fail proof is that the device-only completion hook returns True for exactly the node the hierarchical one now refuses. 7 passed. Feature stays ON: the standing boot keeps the full set, reorder included.

…y where the lineage delivers it sgl-project#755 reduces the floor from 1+P+1+1 to 1+P+1: the donated slot BECOMES the next pin, so the two terms share one slot. The mechanism is real, gated per node, and tested -- but its config gate asks three questions about the CONFIG and none about the LINEAGE, and those select for opposite worlds. The gate requires enable_hierarchical_cache, because only a write-through host tier can promise the released anchor still exists. But registry.py routes a hybrid-SSM model WITH hierarchical cache to UnifiedRadixCache (:107-111), and MambaRadixCache -- the only class implementing the reorder -- is reachable only at :133, i.e. only when hierarchical cache is OFF: hierarchical=False -> reduction NOT taken (floor 24) | MambaRadixCache HAS impl hierarchical=True -> reduction TAKEN (floor 16) | UnifiedRadixCache NO impl Inverted in both rows. CacheInitParams.mamba_slot_reorder is filled from that same predicate on every boot (kv_cache_builder.py:237) and read only by mamba_radix_cache.py:525 -- always False where it is read, always ignored where it is True. The unified lineage's real demand was measured against the code, not assumed, and it is the FULL 1+P+1+1: * replacement slot allocated before the donation -- mamba_component.py:565 (_alloc_mamba_slot), called at :784/:757/:793 before donate_mamba_ping_pong_slot (memory_pool.py:1823), so a request transiently holds active + donated; * resume-anchor pin -- unified_radix_cache.py:1103, inc_lock_ref(new_last_node) right after insert at :1081, reaching MambaComponent.acquire_component_lock (mamba_component.py:491), which is what makes a STATE SLOT unevictable; * grep for mamba_slot_reorder across unified_radix_cache.py and unified_cache_components/ returns zero hits; MambaComponent's donate flow performs the un-reordered sequence regardless of the param. This was not cosmetic. schedule_policy.py:795-801 sizes the ADMISSION budget from mamba_slots_per_running_req for this same lineage (the branch keys on HybridReqToTokenPool, which is the token pool for BOTH trees; the "non-unified" in its comment refers to --enable-unified-memory, a different axis). So the standing boot charged 2 slots per request at both the floor and admission while the runtime held 3: a live one-slot-per-request under-floor, which is the sgl-project#581 direction -- the boot validates a pool the runtime over-draws and the shortfall surfaces late. The fix is a lineage predicate, and the capability is a module CONSTANT, not a config flag: it describes what the code can do, and an operator must never be able to assert it. Porting the reorder into the unified lineage flips UNIFIED_LINEAGE_IMPLEMENTS_SLOT_REORDER and the reduction returns with no other edit. Also adds the boot instrument that would have caught this: _validate_max_mamba_cache_size returns SILENTLY for any pool at or above the floor, so the floor only ever reached a log by REFUSING a boot. A pool sitting exactly on the floor looked identical to a comfortable one. The new MAMBA-FLOOR line states pool, floor and retention budget once at construction, and says plainly when the budget is 0. CONSEQUENCE, stated rather than left to be discovered: on the standing boot (--max-mamba-cache-size 24, --max-running-requests 8) the honest floor is 24, so the pool sits exactly ON it and the retention budget is 0 -- every mamba write-through backup is declined. That is the true posture, not a new restriction: the pool was always fully committed to the running set, the accounting just claimed otherwise. Buying cache retention means raising the pool, or implementing the reorder so the floor honestly falls to 16. The three sgl-project#755 tests that asserted the reduction from config alone now assert it under an explicit lineage patch. They test the MECHANISM's arithmetic, which is unchanged; what moved is where it is reachable. TESTS: test_mamba_reorder_lineage_773.py, 6 tests + 3 subtests. Can-fail EXECUTED: removing the lineage check fails 2. The original three gate conditions are each shown to still refuse on their own, so the gate was narrowed and not silently widened. Direction is asserted explicitly: the refused reduction moves the floor UP by exactly one slot per running request. REGRESSION: test/registered/unit/mem_cache/ = 1455 passed, 8 failed, the same 8 as an untouched HEAD worktree, diffed name-for-name.

… unified lineage The previous commit refused the sgl-project#755 floor reduction because the lineage that gets built does not implement the mechanism. This builds it, and the floor drops back to 1+P+1 -- honestly this time, because the runtime now does what the arithmetic claims. MECHANISM. cache_unfinished_req releases the OLD anchor's mamba pin BEFORE the donation allocation instead of after the insert, so the old and new anchors never coexist and a running request holds active + donated rather than active + donated + old pin. That is the slot, and on the standing boot (max_running_requests 8) it is 8 of them. STRICTLY SAFER THAN THE ORIGINAL, and this is why the port was worth doing rather than re-gating. MambaRadixCache releases the WHOLE node lock early; inc_lock_ref walks ancestors for the FULL component, so its window also leaves the request's own matched KV prefix evictable. The unified tree locks per component, so dec_mamba_lock_only drops ONLY the mamba lock: the KV path stays protected and the single state slot being un-double-counted is the only thing made evictable. dec_swa_lock_only is the same shape for SWA, so this is the file's existing idiom. PER-NODE GATE. The config predicate cannot know whether THIS anchor survives losing its slot, so MambaComponent.anchor_release_admissible asks again: the node must carry a host copy (an evicted-but-backed anchor is a valid match that triggers load_back -- is_resume_candidate's device_only=False rule), and that copy must have LANDED. sgl-project#767: write-through publishes host_value the moment the transfer is handed to the controller and records the node in ongoing_write_through in the same block; between those two facts the anchor is an intention only, and releasing there is the dead anchor the gate exists to prevent. PAIRING, which is where this class of change goes wrong (sgl-project#583). Two exit paths, both handled: * the normal path skips the mamba half at the usual dec_lock_ref, via the skip_lock_node_ids set the components already consult -- a ref that was never taken must not be given back; * the bail path (nothing inserted, so no new anchor takes over the pin and req.last_node is unchanged) RE-ACQUIRES, restoring the exact pre-call state rather than carrying an imbalance into the next call. TESTS: test_mamba_reorder_unified_773.py, 17 tests, CPU-only. The end-to-end pair is the real proof: the pool is sized so the donation allocation can only succeed if the old anchor was released first (2 slots = one active + one anchor, free = 0). A backed anchor caches; an unbacked one, identical in every other respect, does not. That is the saved slot, observed as behaviour rather than as arithmetic. CAN-FAIL, ALL EXECUTED, and three of them were earned the hard way: * unwiring the reorder in cache_unfinished_req -> 1 fails * dropping the skip set -> 1 fails * dropping the bail re-acquire -> 1 fails The last two SURVIVED the first version of this file, because every pairing test simulated the sequence by hand instead of driving the entry point. release_component_lock no-ops at zero, so a double release on a singly-held node hides completely; it only shows when the anchor has a SECOND holder, whose ref the unskipped release would steal. Both tests were rewritten to go through cache_unfinished_req, and the skip-set case needed a spare slot -- with a full pool the step bails and correctly restores the pin, which is a different path and now has its own test. Floor on the standing boot: 24 -> 16. The retention budget introduced in 703b05c becomes 8 slots instead of 0, so mamba host backups are possible again rather than uniformly declined. REGRESSION: test/registered/unit/mem_cache/ = 1473 passed, 8 failed, the same 8 as an untouched HEAD worktree, diffed name-for-name.

…o errors of mine TWO DEFECTS I INTRODUCED IN 5a1113e AND FOUND BEFORE ANY BOOT USED THEM. Both are recorded here rather than quietly repaired, because the second one is a false claim I put in a commit message. DEFECT 1 -- THE ACTUATOR WOULD HAVE INFLATED THE POOL. The demand path multiplies by _calculate_mamba_ratio(), not by the floor's per_req. That returns MAMBA_CACHE_SIZE_MAX_RUNNING_REQUESTS_RATIO (3) plus a buffer term, i.e. 3 on the standing boot, while the floor's per_req is 2. So dropping --max-mamba-cache-size would have derived max(ceil(8 * 3 * 1.25), 3, floor 16) = 30 against the 24 it was meant to replace: SIX SLOTS MORE per rank, and max_total_num_tokens DOWN. 5a1113e's message claims "pool 20"; that was true only of a test that passed ratio=2 by hand and never exercised the call site. Root cause is this task's own family defect once more. _calculate_mamba_ratio is a SECOND statement of "slots per running request" while mamba_pool_floor is the declared single source of truth for it. They agreed for every shape that existed when they were written; sgl-project#755 then taught the FLOOR about the lock reorder and nobody taught the RATIO. Measured across all five shapes: reorder OFF -> identical everywhere except extra_buffer_lazy, where the floor deliberately charges the transient second ping-pong slot (5) and this ratio does not (4); reorder ON -> this ratio overstates by exactly one slot per request in every configuration the reorder applies to. min() is therefore the exact repair: it moves nothing that already agreed, keeps lazy's deliberately smaller sizing ratio, and stops the ratio claiming a slot the floor no longer reserves. Corrected derivation for the standing boot: ratio 2, floor 16, pool 20, retention budget 4. DEFECT 2 -- I CLAIMED A CLEAN SUITE I HAD NOT CHECKED. 5a1113e says "mem_cache unchanged". It was not: the widened gate added a self._mamba_demand_target_is_stated() call that seven stub-driven tests in test_mamba_checkpoint_interval.py could not resolve. I ran that suite, saw 15 failures against a control of 8, and did not compare the two numbers. The repo had already built the guard for this exact mistake. _HANDLE_MAX_MAMBA_CACHE_SELF_CALLS plus its transitive-closure check exist because a0ed7dc added `self._auto_mamba_demand_active()` to the same function without extending the list, breaking four tests that nobody could see for six weeks. I reproduced that incident and its own guard caught me. The repair is the one the harness documents: declare the name. TESTS: test_mamba_pool_from_floor_773.py grows to 13 tests + 9 subtests. The new class asserts the ratio in BOTH directions -- that it no longer overstates under the reorder, and that every pre-reorder shape is byte-identical (no_buffer 3, extra_buffer+overlap 5, extra_buffer 4, extra_buffer_lazy 4, disable_radix 1), lazy included precisely because it is the one shape where the floor is larger and min() must NOT inflate. Can-fail EXECUTED: removing the cap fails 3. test_mamba_checkpoint_interval.py: 39 passed, 19 skipped. METAL, from boot_798_0822_0810.log (r6, commit ef9ccb6), all three ranks, matching the prediction made before the boot: MAMBA-FLOOR pool=24 floor=16 retention_budget=8 (8 running requests x (1 active + 0 ping-pong + 1 donation/pinned checkpoint (sgl-project#755 reorder: the donated slot BECOMES the pin, so the two share)) = 8 x 2 = 16 slots) floor=16 not 24 means the ported reorder ARMS in production; ping-pong 0 confirms the no_buffer reading; the retention budget is bounded and enforced where it was previously unbounded. Zero pin-budget refusals and zero reorder skips over the boot. REGRESSION: model_executor + mem_cache = 2222 passed, 23 failed, and those 23 are name-for-name identical to a control worktree with my commits reverted. Diffed, not eyeballed -- which is the lesson from defect 2.

… point The sizing tests in model_executor/test_mamba_pool_from_floor_773.py call _auto_mamba_demand_size(ratio) with a ratio passed BY HAND. That is exactly how the ratio defect shipped: the hand-passed 2 proved a number the call site never computes, while handle_max_mamba_cache multiplies by _calculate_mamba_ratio() and would have derived 30 -- larger than the hand-pinned 24 it was meant to replace. A test that chooses its own inputs cannot catch that, so this one drives handle_max_mamba_cache itself, bound from the real class, and reads the size the production path installs. It also pins a COUPLING that is easy to miss and expensive to get wrong. Removing --max-mamba-cache-size is only an improvement while the sgl-project#755 reorder ARMS. Unarmed, the floor is 1+P+1+1, the capped ratio follows it back up to 3, and the derived pool becomes 30 -- a REGRESSION of 225 MiB per rank against the pin it replaced. The two changes are therefore not independent, and a boot that drops the pin must confirm floor=16 on the MAMBA-FLOOR line before trusting the pool it is handed. Can-fail EXECUTED: restoring the uncapped ratio (the bug as shipped in 5a1113e) fails 2 of these 4 -- the failure the hand-passed tests could not see. Numbers are PP0, the binding rank, from boot_798_0822_0646: 0.877 GiB of main mamba state over 24 slots = 37.42 MiB per request, 12.153 GiB of post-weights budget. CONFIRMED ON METAL by boot_798_0822_0829 (r7, this branch with the pin removed from the argv), all three ranks: MAMBA-FLOOR pool=20 floor=16 retention_budget=4 and max_total_num_tokens 1198400 -> 1222016 on PP0's sizing line, +23616 tokens, +1.97%. Not 30 (the ratio cap took) and not 24 (the pin is gone). REGRESSION: test/registered/unit/mem_cache/ failures identical to a control worktree with my commits reverted, diffed name-for-name.

…he pin's door is on the prefill path CHECKED BEFORE BUILDING, as ordered, and the check changed the answer. NOTE_888b §5 recorded "pin release ABSENT" for the mamba anchor pin, taking NOTE_773's deferral at its word. That was wrong in the safe direction, and my own sgl-project#902 row inherited it verbatim. WHAT IS ACTUALLY ON THIS BASE. sgl-project#755's reorder release EXISTS: `UnifiedRadixCache._mamba_anchor_early_release` (:1022), guarded by `MambaComponent.anchor_release_admissible` (:564) -- which requires the host copy to have LANDED (`host_value` present AND the node absent from `ongoing_write_through`), not merely to have been intended. That guard is precisely the dead-anchor case sgl-project#767 documents, and it is already built. WHAT IS NOT. Its ONLY call site is `cache_unfinished_req` (:1173), which runs while prefill batches are built. So the door lives on the PREFILL path, and finish releases the pin with everything else the request holds. Under strict purity the TP window forbids prefill and the seam RETRACTS rather than finishes -- so in the TP layout no door opens at all. sgl-project#811 IS THE LAYOUT-INDEPENDENT DOOR AND IS NOT HERE. `[sgl-project#811] Release the mamba admission anchor pin at the write-through ack`, 14606c6 on `fix/811-admission-pin-ack-release`, cut from integ/round7 @ a2a47b4. That parent IS in this base's ancestry; the sgl-project#811 commit is NOT, and its metal proof is still the open W-811 window ticket. So the honest outcome is neither "just declare it reachable" nor a duplicate build: the row is corrected to the doors that exist, and the finding SHARPENS from "no door" to "no door THIS layout can open". `gated_by`, AND THE CHECK READS IT. The prefill door sits behind `mamba_slot_reorder_active` -- three conditions, any of which turns it off. A door behind an unarmed flag is SHUT, so the condition is a field rather than a sentence, and `release_path_conformance` emits a third verdict, CONDITIONAL, naming the gate. Adding a field the check ignored would have been the exact defect this file exists to prevent, one commit after I wrote that down. FINDINGS NOW, both true and neither new work: pp: CONDITIONAL mamba_anchor_pin -- prefill door, only while the reorder flag is armed UNREACHABLE kvso_host_region tp: UNREACHABLE mamba_anchor_pin -- strict purity forbids its only path UNREACHABLE kvso_host_region TEST RESULTS (desk, CUDA_VISIBLE_DEVICES=""): * test_release_path_declarations_902.py -- 8 passed. The pin arm now asserts the CORRECTED truth in both layouts (conditional in pp, unreachable in tp) rather than the inherited "undeclared", and every declared symbol still resolves. * REGRESSION: participants / 859 / 773 / 755 suites plus this one -- 61 passed, 0 failed. * ruff clean on both touched files. STILL OPEN, and it is the next slice: kvso_host_region. Unchanged by this commit -- finish/abort only, no layout reaches it.

…freed at park commit CHECKED BEFORE BUILDING, and for the second time in this ticket the check changed the answer. NOTE_888b §5 recorded the kvso host region as "finish/ abort paths ONLY. A parked session holds its host region for its whole life", and my row inherited it verbatim. Both halves are false on this base. THE REGION IS RELEASED AT PARK COMMIT. `_commit_park` (kv_session_spill_destination.py:1459-1464): mgr._free_regions.append(slot.region) mgr.backend._sess_close_slot(t.rpi) and `_release_parked_req`'s own docstring says so in as many words -- it "mirrors release_finished_spilled_req MINUS the region/backend-slot part (already released at park commit)". §5's sweep read the two finish/abort release sites and did not reach the park-commit one. AND ITS PATH IS REACHABLE FROM BOTH LAYOUTS. The park flow runs in `KVSessionOffloadManager.pre_schedule` (kv_session_offload.py:4791), called from `Scheduler.get_next_batch_to_run` (scheduler.py:6972) -- the per-round batch builder, gated by neither decode nor prefill. What a parked session still holds is the SpillSlot payload (kept WHOLE so unparking "just reattaches a region"), whose door is `_release_parked_req` on that same per-round path. SO THERE WAS NOTHING TO BUILD. The ticket's option was "build a layout-reachable release path"; one exists, and building a second would have been a duplicate actuator on a path that already has one. The #888b relief pattern's own discipline is that the binder is NAMED FROM MEASUREMENT and never assumed -- and I had no measurement showing this region binds anything. Building anyway would have violated the pattern I was told to follow, on a path whose danger direction is use-after-free. BOTH OF sgl-project#902's FINDINGS WERE INHERITED PROSE, and that is the ticket's real result. The check did its job precisely by being wrong in a way the desk could find: it printed two claims, both were checked, both were corrected at file:line, and neither cost a window. A note that says "held with no door" is not evidence; it is a hypothesis that had never been asked to resolve a symbol. TESTS RESTRUCTURED ONTO A SYNTHETIC POPULATION. The rule arms (UNREACHABLE, UNDECLARED, "the declaration is consulted") now own the rows they judge. A rule test that depends on the live population still containing a defect stops testing the rule the moment someone fixes one -- which is exactly what just happened, twice. One arm still asserts the LIVE verdict on purpose, as a record of what the scheduler says today; if a later commit clears it, that is the assertion that should fail and be updated with its reason. FINDINGS NOW: pp: CONDITIONAL mamba_anchor_pin -- prefill door, only while the sgl-project#755 reorder flag is armed tp: UNREACHABLE mamba_anchor_pin -- strict purity forbids its only path; sgl-project#811 adds the layout-independent door and is not in this ancestry kvso_host_region: no finding. Released at park commit, per-round path. TEST RESULTS (desk, CUDA_VISIBLE_DEVICES=""): * test_release_path_declarations_902.py -- 9 passed. * MUTATION: M1 the declaration is never checked -> 6 failed; M2 `gated_by` is never read (the field-nobody-reads defect, added in the previous commit and now pinned) -> 1 failed; M3 finish/abort treated as reachable -> 3 failed; restored 9 passed. * REGRESSION: participants / 859 / 888 / spill / session suites plus this one -- 280 passed, 3 subtests, 0 failed. * ruff clean on both touched files. WHAT IS ACTUALLY LEFT: one finding, the mamba anchor pin in the TP window, and its fix is already written on `fix/811-admission-pin-ack-release` awaiting the W-811 metal proof. sgl-project#902's job -- make the class evaluable instead of hunted -- is done; the remaining instance has an owner and a ticket.

fix: use REPO_TOKEN

2e01ba8

zhyncs merged commit 5bd06b4 into sgl-project:main Jul 26, 2024

zhyncs deleted the update branch July 26, 2024 19:56

timethink pushed a commit to timethink/sglang that referenced this pull request Mar 9, 2025

fix: use REPO_TOKEN (sgl-project#755)

42fa72d

cherryblo added a commit to cherryblo/sglang-project that referenced this pull request Jul 2, 2026

Merge pull request sgl-project#755 from hhhh1252023/patch-9

cce687b

fix 0611

Navigation Menu

Uh oh!

fix: use REPO_TOKEN - #755

fix: use REPO_TOKEN#755
zhyncs merged 1 commit into
sgl-project:mainfrom
zhyncs:update

zhyncs commented Jul 26, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

zhyncs commented Jul 26, 2024

Motivation

Modification

Checklist

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant