feat(mcp): expose scheduled task run-now#10562

merged1
agents/mcp-thin/thread-search
agents/mcp-thin/scheduled-tasks
openedSep 7, 2026byJJulius Marminge
View on GitHubTwo-way sync enabledPR last imported 4d ago

Part 12/16 of the shared-core and MCP stack. Based on #10561. Next: #10563.

Expose ScheduledTaskService.runNow for tasks in the calling project, using the existing manual-run execution and bookkeeping.

Requires a full-access/default caller. Each call is a new manual run, not an idempotent retry. Returned bookkeeping is not provider turn completion; durable keyed retries and scheduler hardening are separate.

MCP-only rebuild of #8731, preserving attribution to Julius Marminge's original work. Original branches remain available for separate service follow-ups.

Validation: The composed stack passes 94 tests across 12 focused files, including shared core MCP and real MCP/V2 integration, attachment intake, project RPC/service contracts, and client model command selection. Server/contracts/shared/client-runtime typechecks and targeted format/lint/diff checks pass. New behavior coverage lives with the shared operation; no per-tool mock suite was added. Current-head CI is shown below.

Layer size: 3 files, +54/-0. No domain-service production implementation or documentation files change in this MCP layer.

Prepared with Codex in the OpenAI agent runtime.

Synced from GitHub

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new destructive MCP operation that can dispatch scheduled-task provider work and update durable run bookkeeping. Although access is bounded and existing scheduler logic is reused, the new user-facing production workflow has material side effects and warrants human review.

No code changes detected at 06de990. Prior analysis still applies.

You can add or adjust custom eligibility rules. Learn more.

Synced from GitHub

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for 06de990.

This comment will update automatically after the next completed run.

apps/server/src/mcp/toolkits/thread/handlers.tslines 74–103Outdated · 97d1493Open thread
……@@ -69,6 +71,36 @@ const readQuestion = Effect.fn("mcp.readQuestion")(function* (
100+ runCount: task.runCount,
101+ nextRunAt: task.nextRunAt,
102+ };
103+ }),
MmacroscopeappBoton lines 74–103Sep 7, 2026

This adds new backend behavior (a destructive tool that dispatches a scheduler run) with no focused test. Consider covering the two guard branches (non-full-access/non-default caller -> capability_denied, task outside the calling project -> invalid_request) and the happy path using the existing test-layer patterns: Layer.mock(ThreadManagement.ThreadManagementService) as in apps/server/src/mcp/toolkits/core.test.ts, or the in-memory scheduledTaskStubLayer already wired into apps/server/src/mcp/OrchestratorMcpToolkit.integration.test.ts — test layers for the external services only, no mocking of the handler logic itself.

Posted via Macroscope — Effect Service Conventions

Following the maintainer-requested test boundary: this tool calls existing ScheduledTaskService.list/runNow after a direct caller-mode and task-project filter; no scheduler execution, replay or bookkeeping implementation changes. Shared MCP registration/input/caller/error coverage remains in the stack, and ScheduledTaskService retains its isolated behavior tests. We are not adding a separate test suite merely to assert forwarding of the already-typed service call. The PR explicitly documents a new manual run per call and does not promise additional transactional authority or keyed replay.

The concern remains: no existing test invokes this handler. The caller-mode and project guards are tool-local behavior, so shared registration/input coverage and isolated service tests do not exercise them. A focused handler test for those guards and the successful delegation is still warranted.

Added 1 commit

  • feat(mcp): expose manual scheduled task execution06de990