bug: get_run_details has returned a non-progressing zero-limit cursor since PR #3224
維護者通常 1 天內回覆
@AbhayPratap01 已經在處理了。
開始於 2026年8月25日。
評估
- 難度
- 2/5
- 預估耗時
- 1-3 小時
- 新手友好度
- 68/100
- Issue 類型
- 缺陷
- 描述清晰度
- 描述清楚
- 活躍度
- 活躍
- 技術堆疊
- typescript
- 領域
- api
研究方向
從 packages/cli-v3/src/mcp/schemas.ts(GetRunDetailsInput,maxTraceLines 沒有最小值)以及 packages/cli-v3/src/mcp/tools/runs.ts 開始,其中 readLinesPage 將 nextCursor 計算為 offset + limit。為該 schema 加上正整數限制,並在 readLinesPage 加入防禦性檢查,讓零值/負值的 limit 要麼報錯,要麼回傳一個前進的 cursor。以現有的 cli-v3 MCP 工具測試進行驗證,加入 maxTraceLines 為 0、負值與 1 的案例,以確認 nextCursor 從 "0" 遞進到 "1"。
由索引模型根據 Issue 內容生成。
描述
Provide environment information
System:
OS: macOS 26.5.2
CPU: (10) arm64 Apple M4
Memory: 1.82 GB / 16.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 24.19.0
npm: 11.7.0
pnpm: 11.19.0
bun: 1.3.14
Trigger.dev:
CLI and SDK: 4.5.11
MCP transport: stdio
Flags: --dev-only --readonly
Environment: dev
Describe the bug
The MCP get_run_details tool accepts maxTraceLines: 0 and reports a
successful empty page with nextCursor: "0". Following that cursor requests
the same page again, so pagination cannot advance.
I found this while testing Trigger.dev's MCP surface with an internal agent
compatibility system at Bottomless. The reproduction is model-free and uses a
dedicated benchmark dev project.
Expected behavior: reject a page size below one, or return a cursor that
advances.
Actual behavior:
Run Trace (lines 1-0 of 43)
More trace available.
nextCursor: "0"
To reproduce
- Start the official Trigger.dev MCP for a project that has a completed dev
run. - Call
get_run_detailsfor that run withmaxTraceLines: 0. - Observe that the call succeeds, reports
lines 1-0, and returns cursor
"0"while saying more trace is available. - Call the tool again with cursor
"0"; it returns the same page.
Reduced arguments:
{
"projectRef": "<project-ref>",
"environment": "dev",
"runId": "<completed-run-id>",
"maxTraceLines": 0
}
A control call with maxTraceLines: 1 returns lines 1-1 and cursor "1".
Additional information
I traced the behavior through Main history. The non-progressing cursor path was
introduced by PR #3224,
feat(cli): Expand and improve the MCP server and dev CLI command, merged on
March 17, 2026 at commit
dbbe9f77f953ad7a8306e48d7bd1107e3f8d3ba2.
Before that PR, maxTraceLines existed but get_run_details did not return a
cursor. PR #3224 added cursor pagination while leaving the zero value valid.
Its new readLinesPage function computed nextCursor as offset + limit, so
a zero limit returned the same cursor indefinitely.
The schema still accepted every integer when I rechecked Main on August 20,
2026 at 447471843cbe7759f64beb616d5db5f05696ea13, because maxTraceLines has
no minimum:
The same cursor calculation also remains on current Main:
Suggested change: require a positive integer in GetRunDetailsInput, add a
defensive positive-limit check in readLinesPage, and cover zero/negative
limits plus a one-line positive case in tests.
The live check had zero invalid cases, unchanged fixture state, and verified
cleanup. Searches of existing issues and PRs found no matching report. This is
an MCP response-contract issue, not a security report.
We are testing a system at Bottomless that runs repeatable MCP contract and
workflow checks, verifies the observed behavior directly, and can replay the
same checks when an MCP changes. We are trying to learn whether MCP teams would
want checks like this on future pull requests or releases. Would that be useful
to your team?
If useful, I can look into a focused regression test and fix, then rerun the
same check.
- 主要語言
- TypeScript
- 星號
- 16.5k
- 分支
- 1.5k
- 平均合併
- 1 天 15 小時
- 30 天內合併 PR
- 17
環境準備
這個專案沒有提供開發容器、Dockerfile 或貢獻指南,環境需要你自己搭建:先看它的 README,通用步驟見我們的新手貢獻指南。
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
triggerdotdev/trigger.dev 的其他 Issue
-
bug: retry.fetch ignores the caller's abort signal and retries aborted requests可能重新可做 關聯的 PR 已關閉且未合併。 未關閉
難度 2/5 1-3 小時 新手友好度 76/100
triggerdotdev/trigger.dev#5116 · 2 則留言 ·
維護者通常 1 天內回覆
-
bug: Chat transport crashes on Safari < 17.4: AbortSignal.any is not a function可能重新可做 關聯的 PR 已關閉且未合併。 未關閉
難度 2/5 1-3 小時 新手友好度 83/100
triggerdotdev/trigger.dev#5098 · 2 則留言 ·
維護者通常 1 天內回覆
-
bug: Side menu items lose their active state on detail pages可能重新可做 關聯的 PR 已關閉且未合併。 未關閉
難度 2/5 1-3 小時 新手友好度 72/100
triggerdotdev/trigger.dev#5088 ·
維護者通常 1 天內回覆
-
bug: RBAC loader logs "plugin found but failed to load" when @triggerdotdev/plugins is simply not installed可能重新可做 @itsfaryal 於 17 天前認領,目前沒有進行中的 PR。 未關閉
難度 2/5 1-3 小時 新手友好度 82/100
triggerdotdev/trigger.dev#5083 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 83/100
triggerdotdev/trigger.dev#5072 · 1 則留言 ·
維護者通常 1 天內回覆
查看 triggerdotdev/trigger.dev 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
bug platform-android
難度 2/5 1-3 小時 新手友好度 68/100
Termix-SSH/Mobile#146 · 1 則留言 ·
維護者通常 2 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 66/100
devswha/herdr-web-ui#3875 ·
-
難度 1/5 1 小時以內 新手友好度 88/100
-
area: runtime chore cli consistency dependencies developer-experience difficulty: easy discovery documentation enhancement good first issue help wanted hygiene json-output packaging priority: P3 tests version
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆