← Back to PRs

#9430: fix: accept flat params for cron.add tool action

by dbottme open 2026-02-05 06:36 View on GitHub →
agents stale
## Summary Fixes #9283 The `cron.add` tool now accepts BOTH formats for creating cron jobs: ### Flat params (PREFERRED - matches Gateway schema): ```json { "action": "add", "name": "test-job", "schedule": { "kind": "cron", "expr": "0 5 * * *" }, "payload": { "kind": "systemEvent", "text": "hello" }, "sessionTarget": "main" } ``` ### Nested job object (legacy/alternative): ```json { "action": "add", "job": { "name": "test-job", "schedule": { ... }, ... } } ``` ## Problem The cron tool schema expected a nested `job: {...}` object, but the Gateway validator expected flat top-level parameters (`name`, `schedule`, `sessionTarget`, `payload`). This caused a schema mismatch that led to: - LLMs generating tool calls with nested `job` objects - Gateway rejecting the request with validation errors like `must have required property 'name'` - Infinite retry loops in some agents ## Solution - Updated the tool schema to accept flat job parameters at the top level - Modified the execute handler to build a job object from flat params when provided - Flat params take priority when both formats are provided - Updated tool description to document both formats ## Changes - `src/agents/tools/cron-tool.ts`: Added flat param support to schema and handler - `src/agents/tools/cron-tool.test.ts`: Added tests for flat params scenarios <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates the `cron.add` tool to accept both the legacy nested `{ job: {...} }` format and a new flat top-level parameter format (`name`, `schedule`, `payload`, `sessionTarget`, etc.) to match the Gateway validator. The tool schema is broadened to include these flat fields, and the execute handler now constructs a job object from flat params (taking priority over `job` when both are present). Tests were added to cover the flat format and precedence behavior. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge after addressing a small but real edge-case in flat-param detection for cron.add. - Changes are localized to the cron tool schema/handler and are covered by targeted unit tests, but the current `hasFlatParams` heuristic can reject valid-looking flat-format calls that only include sessionTarget/flags (or other flat fields) and omit name/schedule/payload until later, producing an unexpected "job required" error. - src/agents/tools/cron-tool.ts <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs