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 天内回复