The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jun 11, 2026 7:48pm

PR Summary

Medium Risk
Large new integration surface that can start, cancel, terminate, and reset customer Temporal workflows when agents use it; misconfiguration or overly broad credentials could cause production impact, though it does not change Sim’s own auth.

Overview
Adds a Temporal DevOps integration so Sim agents and workflows can call a cluster’s HTTP API (serverUrl, namespace, optional Bearer apiKey).

Runtime: Twenty new tools under apps/sim/tools/temporal/ cover workflow lifecycle (start, signal, signal-with-start, query, update, describe, list, count, history, cancel, terminate, reset), task-queue pollers, and schedule CRUD plus pause/unpause/trigger. Shared helpers encode/decode json/plain payloads and use Accept: application/json+no-payload-shorthand for stable responses. Tools are registered in apps/sim/tools/registry.ts.

Product surface: A Temporal block maps an operation dropdown to temporal_${operation} with conditional sub-blocks, advanced options (ID policies, timeouts, memo, search attributes, pagination), and wand prompts for JSON args, visibility filters, and cron. TemporalBlockMeta adds templates and skills. integrations.json, block registry, and icon mappings are updated; TemporalIcon is added in docs and sim.

Docs: New temporal.mdx (manual intro + generated action tables) and temporal in integrations meta.json.

^{Reviewed by Cursor Bugbot for commit ef53b1b. Configure here.}

@greptile

@cursor review

Greptile Summary

This PR adds a full Temporal integration (20 tools) over Temporal's HTTP API, covering workflow lifecycle management (start, signal, signal-with-start, query, update, describe, list, count, history, cancel, terminate, reset), task queue introspection, and schedule management (create, list, describe, pause, unpause, trigger, delete). Inputs and results use Temporal's json/plain payload encoding with the application/json+no-payload-shorthand accept header for deterministic decoding.

• All 20 tool configs follow the project's ToolConfig pattern with correct params, request, and transformResponse fields; requestId: generateId() is included on every write operation whose proto carries a request_id field.
• utils.ts centralises URL building, payload encode/decode, response error parsing, and execution/history mappers; field names are aligned with the Temporal proto camelCase JSON conventions verified against the HTTP gateway route bindings.
• Block config in temporal.ts exposes all tools through a single operation dropdown with conditional subBlock visibility; docs page and icon/registry wiring are also included.

Confidence Score: 5/5

Safe to merge; all 20 tools have correct Temporal HTTP API field names, URL structures, payload encoding, and request ID coverage.

The implementation is a large but well-structured addition. Request bodies use the correct camelCase proto field names (verified against the Temporal HTTP gateway route bindings), json/plain payload encoding is correct, and every write operation that carries a request_id proto field includes one. The only finding is a module-level Buffer.from call in utils.ts that could break in edge runtimes, but tools execute server-side in this project so it poses no practical risk today.

apps/sim/tools/temporal/utils.ts — the top-level Buffer.from call is worth addressing for future portability.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant User as User/LLM
    participant Block as Temporal Block
    participant Tool as Tool Config
    participant Utils as utils.ts
    participant Server as Temporal HTTP API

    User->>Block: Select operation + params
    Block->>Tool: Resolve tool by operation
    Tool->>Utils: temporalNamespaceUrl / temporalWorkflowUrl / temporalScheduleUrl
    Tool->>Utils: temporalRequestHeaders (Bearer token if apiKey)
    Tool->>Utils: parseJsonArgs / parseJsonPayloadMap (encode payloads)
    Tool->>Utils: generateId() → requestId
    Tool->>Server: "POST/GET/DELETE /api/v1/namespaces/{ns}/workflows/{id}/..."
    Note over Tool,Server: Accept: application/json+no-payload-shorthand
    Server-->>Tool: JSON response (full payload objects)
    Tool->>Utils: parseTemporalResponse (error on non-2xx)
    Tool->>Utils: decodePayload / decodePayloads / decodePayloadMap
    Tool->>Utils: mapExecutionInfo / mapHistoryEvent / stripEnumPrefix
    Tool-->>Block: Typed output (workflowId, runId, result, …)
    Block-->>User: Output data

_{Reviews (5): Last reviewed commit: "improvement(temporal): send requestId on..." | Re-trigger Greptile}

@greptile The update_workflow finding was based on a misread of the proto — UpdateWorkflowExecutionResponse.outcome is update.v1.Outcome (the success/failure oneof directly), not a update.v1.Response wrapper. See the thread reply for citations. Please re-review.

@greptile Pushed ef53b1b adding requestId: generateId() to signal_workflow, cancel_workflow, pause_schedule, unpause_schedule, and trigger_schedule (every write op whose request message carries request_id; terminate has no such field). Please re-review.

@cursor review

@greptile Your latest summary appears to have analyzed the pre-fix tree — as of the reviewed commit ef53b1b, signal_workflow.ts, trigger_schedule.ts, pause_schedule.ts, unpause_schedule.ts, and cancel_workflow.ts all send requestId: generateId() in their request bodies (see the body builders in each file — e.g. signal_workflow.ts). Every write operation whose request message carries request_id now includes it; terminate_workflow is the only write without one because TerminateWorkflowExecutionRequest has no request_id field. Please re-review the current head.