feat: trigger execution queuing, fan-out, and MCP rate limiting#2772
Draft
feat: trigger execution queuing, fan-out, and MCP rate limiting#2772
Conversation
- Explicitly set defaults for maxConcurrentInvocations, staggerIntervalSeconds, and audienceConfig in create route - Add tests for creating triggers with concurrency control fields - Add tests for creating triggers with audience config - Add tests for default values of new fields - Add tests for updating concurrency and audience fields - Add tests for clearing audience config - Add tests for recipientUserId in invocation list responses - Verify GET returns new fields in list and single trigger responses
…unner - Add createFanOutInvocationsStep that creates N invocations for audience userIds - Each invocation gets recipientUserId and unique idempotency key (prefix_userId) - Runner checks audienceConfig and uses fan-out or single creation accordingly - Non-audience triggers continue creating exactly one invocation (unchanged) - Add 4 tests: fan-out creation, idempotency keys, duplicate prevention, regression
Add processInvocationBatchStep that processes multiple invocations with configurable maxConcurrentInvocations and staggerIntervalSeconds. The fan-out path in the runner now uses batch processing with parallel execution, while the single-invocation path remains unchanged. - Add countRunningInvocationsForTrigger data access function - Add countRunningInvocationsStep, listAllPendingInvocationsStep, and processInvocationBatchStep step functions - Restructure runner fan-out branch for batch processing - Add 5 integration tests for concurrency control behavior
Single invocation path now uses invocation.recipientUserId as runAsUserId override when present, falling back to trigger's runAsUserId. The batch/ fan-out path already had this logic in processInvocationBatchStep.
McpRateLimiter with token bucket per (tenantId, toolId) tuple supporting requestsPerMinute, requestsPerHour, and concurrentRequests limits. Acquires block with configurable timeout and throw McpRateLimitError. Buckets are lazily created and cleaned up after inactivity.
McpClient.tools() execute callback now checks rate limiter before calling callTool(). Rate limiter is injected via McpClientOptions when tool has rateLimits configured. AgentMcpManager passes a global McpRateLimiter singleton and tool's rateLimits config when creating MCP connections. Concurrent request tokens are released in finally block.
rateLimits field already flows through create/update/read via schema and data access layer. Added 6 integration tests: create with rateLimits, create without (null default), reject invalid values, update rateLimits, and clear rateLimits by setting null.
- Fix typecheck errors in audience picker (field.value possibly undefined) - Form already has maxConcurrentInvocations, staggerIntervalSeconds inputs - Form already has audience multi-select user picker for fan-out - API client types updated with new fields
- Add rateLimits schema to form validation (requestsPerMinute, requestsPerHour, concurrentRequests) - Add rate limits fieldset section to MCP server form with number inputs - Wire rateLimits into all three create paths (user-scoped, OAuth, standard) and update path - Map existing rateLimits into edit form initialData - Add cleanRateLimits helper to convert null form values to API-compatible format
- Increase pending invocations fetch limit from 100 to 1000 (matching audience size max) to prevent silent truncation for large audiences - Add try/catch for unique constraint violation in fan-out creation to handle TOCTOU race condition gracefully - Remove unused countRunningInvocationsStep dead code and import
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Ito Test Report ✅20 test cases ran. 20 passed. ✅ All executed checks passed, including scheduled trigger fan-out/execution settings, MCP rate-limit persistence, API validation/tamper resistance, authorization boundaries, and mobile form coverage. 🔍 Verification found no code-supported defect signals in the included results. ✅ Passed (20)
📋 View Recording |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds three composable layers to the scheduled trigger system: execution concurrency control, trigger audience fan-out, and MCP tool rate limiting. Enables customers to configure "daily reports for all employees" without overwhelming external API rate limits.
Full PR body to follow after testing.