feat(custom-blocks): join cross-workspace runs into the caller's trace, and map blocks per environment (#6857)

* feat(custom-blocks): join cross-workspace runs into the caller's trace, and map blocks per environment

Teams that orchestrate work across workspaces have two gaps that keep them on HTTP
blocks instead of custom blocks: they cannot see what a custom block actually did,
and a forked environment silently keeps calling the environment it was forked from.

Debugging. A custom block is an invocation boundary — a published block is org-wide,
so its internals must not reach every consumer by default. The child already writes
its own log row in the source workspace, correlated to the invoking run; the trace
existed, it just was not joined. The parent's span now carries only the child's
opaque execution id, and `hydrateChildTraces` joins the child's spans at READ time,
after authorizing the person reading against the child's workspace. Authorization
follows the viewer rather than a flag set at publish time, re-evaluates on every
read, and needs no second copy of the spans. Each hop of a nested chain is
authorized against its own workspace. Boundaries left unexpanded — no access, no
data, past a cap — say so, because a childless boundary span otherwise renders
exactly like a leaf and a partial trace reads as a complete one.

Live runs stream too, gated on `liveTraceViewerUserId`, which only surfaces with a
single known authenticated viewer set. Chat deployments stream through the same
callbacks and their consumer may be anonymous, so anything that does not opt in
keeps the boundary shut. Child spans handed to such a viewer are projected through
the CHILD's session: the invoking run's registry knows nothing about the publisher's
secrets, so projecting there would leave a source-owner credential unmasked. They
reach the live stream and stop — `createSpanFromLog` still refuses to persist them,
which is what keeps read-time hydration the single authorization point.

Environments. A fork inherits its parent's organization and `custom_block` is keyed
`(organization_id, type)`, so a uat fork resolved to the same row and ran the prod
workflow. Custom blocks become a fork-mappable resource, keyed by BLOCK TYPE — the
rule every kind follows: key by whatever the workflow references, as `file` does
with storage keys and `env-var` with names. A custom block is the only resource
referenced by the canvas block's own type rather than a sub-block value, so the
rewrite gets its own channel. Unmapped blocks keep the source type, because a type
cannot be emptied without deleting the node; they surface as unmapped and block the
promote, which is what stops uat from quietly invoking prod.

Same-named environment copies now carry their source workspace, so an Access Control
allowlist decision between three identical "Invoice Parser" rows is no longer a guess.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(workspace-forking): let an explicit identity custom-block mapping resolve

`remapForkBlockType` reported a mapping whose target equalled the source as
unresolved, conflating "a mapping exists" with "the type string changed". Those
are opposite states that produce an identical output `type`, and every caller
uses the flag for the former — to decide whether the reference blocks a promote.

The org-wide candidate list includes the source block, so binding an environment
to the shared block is a normal pick. Under the old flag it raised
`unmapped-custom-block` and refused the sync over a choice the user had
explicitly made. The flag is now named `resolved` and reports mapping existence;
whether the type moved is already visible from `type`.

Reported by Cursor Bugbot on #6857.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(custom-blocks): keep a streamed child's spans and markers off the parent's log

Two leaks in the live-stream path, both the same mistake: treating a channel as
viewer-scoped when it is actually persisted, so gating the stream on an
authorized viewer bought nothing.

`childTraceSpans` rode the block output to reach the stream. `filterOutputForLog`
only dropped a hidden key when the block's own config declared it
`hiddenFromDisplay` — true of the workflow block, never of a custom block, whose
outputs are publisher-curated. The source run's spans therefore persisted into
the parent's `span.output`, readable by anyone with parent-workspace access and
never re-checked by `hydrateChildTraces`. A globally hidden key is now dropped at
the top level, not only when nested, and `extractDisplayOutput` strips it again so
no other producer can reintroduce it.

The fan-out also called the invoking run's `onBlockStart`/`onBlockComplete`, which
are persist-then-emit composites: they write block names and I/O into the parent's
LoggingSession before reaching the stream. Those markers are keyed by the parent
execution and outlive the per-viewer check entirely. Custom-block children now go
through `liveStreamCallbacks`, the raw emit-only pair, and fail closed when a
surface supplies none. Same-workspace workflow children keep the composites — they
belong to the same run and their markers are legitimately the parent's.

Reported by Cursor Bugbot on #6857.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(custom-blocks): carry the emit-only stream sink into nested executions

Routing custom-block events through `liveStreamCallbacks` forwarded the viewer id
to the child but not the sink itself, so a nested hop cleared
`canStreamCustomBlockToViewer` off the inherited id and then had nothing to stream
through — `parentStreamSink` fell back to `{}` and live traces stopped at the
first sub-executor. That hit a custom block nested inside a workflow block as
readily as one inside another custom block.

The sink now travels with the viewer id, and both are withheld together when
streaming is not permitted. It is always the INHERITED chain, never
`parentStreamSink`: for a same-workspace workflow block that is the persisting
composite, so forwarding it would put a custom block nested inside one straight
back onto the parent's progress markers — the leak the previous commit closed.

Reported by Cursor Bugbot on #6857.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: icecrasher321

apps/sim/app/api/logs/execution/[executionId]/route.ts

@@ -12,6 +12,7 @@ import { executionIdParamsSchema } from '@/lib/api/contracts/logs'
 import { checkSessionOrInternalAuth } from '@/lib/auth/hybrid'
 import { generateRequestId } from '@/lib/core/utils/request'
 import { withRouteHandler } from '@/lib/core/utils/with-route-handler'
+import { hydrateChildTraces } from '@/lib/logs/execution/hydrate-child-traces'
 import { materializeExecutionData } from '@/lib/logs/execution/trace-store'
 import type { TraceSpan, WorkflowExecutionLog } from '@/lib/logs/types'
 import { checkWorkspaceAccess } from '@/lib/workspaces/permissions/utils'
@@ -126,6 +127,14 @@ export const GET = withRouteHandler(
         }
       )) as WorkflowExecutionLog['executionData']
       const traceSpans = (executionData?.traceSpans as TraceSpan[]) || []
+
+      // Join any custom-block child runs first: the spans they contribute carry
+      // their own `childWorkflowSnapshotId`s, so the collection below picks them
+      // up and canvas drill-down works across the workspace boundary too.
+      if (traceSpans.length > 0) {
+        await hydrateChildTraces(traceSpans, { viewerUserId: authenticatedUserId })
+      }
+
       const childSnapshotIds = new Set<string>()
       const collectSnapshotIds = (spans: TraceSpan[]) => {
         spans.forEach((span) => {

apps/sim/app/workspace/[workspaceId]/logs/components/log-details/components/trace-view/trace-view.tsx

@@ -49,6 +49,16 @@ import { BlockTile } from '@/blocks/block-tile'
 import { isCustomBlockType } from '@/blocks/custom/build-config'
 import { useCodeViewerFeatures } from '@/hooks/use-code-viewer'
 
+/**
+ * Why a custom block's steps are not shown under it. `granted` is deliberately absent —
+ * the joined children are their own evidence, so labelling them would be noise.
+ */
+const CHILD_TRACE_ACCESS_LABEL: Record<string, string> = {
+  denied: 'No access to the source workspace',
+  missing: 'Not available',
+  truncated: 'Not expanded (nesting limit)',
+}
+
 const DEFAULT_TREE_PANE_WIDTH = 240
 const MIN_TREE_PANE_WIDTH = 200
 const MAX_TREE_PANE_WIDTH = 600
@@ -672,6 +682,13 @@ const TraceDetailPane = memo(function TraceDetailPane({ span }: { span: TraceSpa
     label: 'Type',
     value: isCustomBlockType(span.type) ? 'custom block' : span.type,
   })
+  // A custom block runs in another workspace, so its steps are joined in only for a viewer
+  // authorized there. Say why they are absent — otherwise a boundary span with no children
+  // is indistinguishable from a block that simply did nothing.
+  const childRunLabel = span.childTraceAccess
+    ? CHILD_TRACE_ACCESS_LABEL[span.childTraceAccess]
+    : undefined
+  if (childRunLabel) metaEntries.push({ label: 'Child run', value: childRunLabel })
   metaEntries.push({ label: 'Duration', value: formatDuration(duration, { precision: 2 }) || '—' })
   if (span.tries !== undefined) metaEntries.push({ label: 'Tries', value: String(span.tries) })
   if (span.provider) metaEntries.push({ label: 'Provider', value: span.provider })

apps/sim/app/workspace/[workspaceId]/providers/custom-blocks-loader.tsx

@@ -36,6 +36,7 @@ export function CustomBlocksLoader() {
             name: block.name,
             description: block.description,
             workflowId: block.workflowId,
+            workspaceName: block.workspaceName,
             exposedOutputs: block.exposedOutputs,
           },
           block.inputFields,

apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/terminal/utils.test.ts

@@ -8,8 +8,12 @@ vi.mock('@/blocks', () => ({
 }))
 
 vi.mock('@/executor/constants', () => ({
-  isWorkflowBlockType: vi.fn((blockType: string | undefined) => {
-    return blockType === 'workflow' || blockType === 'workflow_input'
+  isSubExecutionBlockType: vi.fn((blockType: string | undefined) => {
+    return (
+      blockType === 'workflow' ||
+      blockType === 'workflow_input' ||
+      blockType?.startsWith('custom_block_') === true
+    )
   }),
 }))
 

apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/terminal/utils.ts

@@ -1,7 +1,7 @@
 import type React from 'react'
 import { Ban, CircleX, Repeat, Split, TriangleAlert, Workflow } from '@sim/emcn/icons'
 import { getBlock } from '@/blocks'
-import { isWorkflowBlockType } from '@/executor/constants'
+import { isSubExecutionBlockType } from '@/executor/constants'
 import { TERMINAL_BLOCK_COLUMN_WIDTH } from '@/stores/constants'
 import type { ConsoleEntry } from '@/stores/terminal'
 
@@ -184,7 +184,7 @@ function collectWorkflowDescendants(
   const direct = workflowChildGroups.get(instanceKey) ?? []
   const result = [...direct]
   for (const entry of direct) {
-    if (isWorkflowBlockType(entry.blockType)) {
+    if (isSubExecutionBlockType(entry.blockType)) {
       // Use childWorkflowInstanceId when available (unique per-invocation) to correctly
       // separate children across loop iterations of the same workflow block.
       result.push(
@@ -481,7 +481,7 @@ export function buildEntryTree(entries: ConsoleEntry[], idPrefix = ''): EntryNod
             return true
           })
           .map((block) => {
-            if (isWorkflowBlockType(block.blockType)) {
+            if (isSubExecutionBlockType(block.blockType)) {
               const instanceKey = block.childWorkflowInstanceId ?? block.blockId
               const allDescendants = collectWorkflowDescendants(instanceKey, workflowChildGroups)
               const rawChildren = allDescendants.map((c) => ({
@@ -524,7 +524,7 @@ export function buildEntryTree(entries: ConsoleEntry[], idPrefix = ''): EntryNod
   const remainingRegularBlocks: ConsoleEntry[] = []
 
   for (const block of regularBlocks) {
-    if (isWorkflowBlockType(block.blockType)) {
+    if (isSubExecutionBlockType(block.blockType)) {
       const instanceKey = block.childWorkflowInstanceId ?? block.blockId
       const allDescendants = collectWorkflowDescendants(instanceKey, workflowChildGroups)
       const rawChildren = allDescendants.map((c) => ({

apps/sim/blocks/custom/build-config.test.ts

@@ -151,3 +151,30 @@ describe('buildCustomBlockConfig', () => {
     expect(JSON.parse(json as string)).toEqual({ title: 'Acme', count: 3 })
   })
 })
+
+describe('sourceWorkspaceName', () => {
+  const icon = () => null as never
+
+  it('carries the source workspace so same-named environment copies stay distinguishable', () => {
+    // prod/uat/sandbox copies of one block share a name and differ only by an opaque
+    // `custom_block_<slug>` type. Without the workspace, an allowlist decision in Access
+    // Control — or any other list of blocks — is a coin flip between three identical rows.
+    const prod = buildCustomBlockConfig({ ...row, workspaceName: 'Impl (prod)' }, [], { icon })
+    const uat = buildCustomBlockConfig(
+      { ...row, type: 'custom_block_uat999', workspaceName: 'Impl (uat)' },
+      [],
+      { icon }
+    )
+
+    expect(prod.name).toBe(uat.name)
+    expect(prod.sourceWorkspaceName).toBe('Impl (prod)')
+    expect(uat.sourceWorkspaceName).toBe('Impl (uat)')
+  })
+
+  it('is omitted when the workspace is unknown, so no empty suffix renders', () => {
+    expect(buildCustomBlockConfig(row, [], { icon }).sourceWorkspaceName).toBeUndefined()
+    expect(
+      buildCustomBlockConfig({ ...row, workspaceName: null }, [], { icon }).sourceWorkspaceName
+    ).toBeUndefined()
+  })
+})

apps/sim/blocks/custom/build-config.ts

@@ -45,6 +45,8 @@ export interface CustomBlockRow {
   name: string
   description: string
   workflowId: string
+  /** Source workflow's home workspace name, to disambiguate same-named env copies. */
+  workspaceName?: string | null
   /** Curated exposed outputs; empty/absent exposes the child's whole `result`. */
   exposedOutputs?: CustomBlockOutput[]
 }
@@ -154,6 +156,7 @@ export function buildCustomBlockConfig(
     name: row.name,
     description: row.description,
     sourceWorkflowId: row.workflowId,
+    ...(row.workspaceName ? { sourceWorkspaceName: row.workspaceName } : {}),
     category: 'tools',
     longDescription:
       'A published workflow packaged as a reusable, self-contained block. Fill its input ' +

apps/sim/blocks/types.ts

@@ -638,6 +638,13 @@ export interface BlockConfig<T extends ToolResponse = ToolResponse> {
    * (placing it would recurse).
    */
   sourceWorkflowId?: string
+  /**
+   * For published custom blocks only: the name of the workspace the bound source
+   * workflow lives in. Display-only, and the sole way to tell two blocks apart when
+   * an org runs the same block per environment — prod/uat/sandbox copies share a
+   * name and differ only by an opaque `custom_block_<slug>` type.
+   */
+  sourceWorkspaceName?: string
   /**
    * Marks an unreleased block. Preview blocks are hidden from every discovery
    * surface (toolbar, search, mentions, copilot/VFS, docs) in every environment —

apps/sim/ee/access-control/components/group-detail.tsx

@@ -756,6 +756,15 @@ function BlockToolRow({
           )}
         >
           <span className='truncate text-sm'>{block.name}</span>
+          {/* An org running one custom block per environment has prod/uat/sandbox copies
+              sharing a name and differing only by an opaque type slug. The source workspace
+              is the only thing that tells them apart, so an allowlist decision made without
+              it is a guess. */}
+          {block.sourceWorkspaceName && (
+            <span className='flex-shrink-0 text-[var(--text-muted)] text-caption'>
+              {block.sourceWorkspaceName}
+            </span>
+          )}
           {isBlockAllowed && deniedCount > 0 && (
             <ChipTag variant='gray' className='flex-shrink-0'>
               {deniedCount} blocked
@@ -1787,6 +1796,11 @@ export function GroupDetail({
                             {BlockIcon && <BlockIcon className='!size-[9px] text-white' />}
                           </div>
                           <span className='truncate text-sm'>{block.name}</span>
+                          {block.sourceWorkspaceName && (
+                            <span className='flex-shrink-0 text-[var(--text-muted)] text-caption'>
+                              {block.sourceWorkspaceName}
+                            </span>
+                          )}
                         </label>
                         {block.description && (
                           <Info side='top' className='flex-shrink-0'>

apps/sim/ee/workspace-forking/components/fork-sync/cleared-refs-list.ts

@@ -69,6 +69,7 @@ export const FORK_RESOURCE_KIND_LABEL: Record<string, string> = {
   'knowledge-base': 'knowledge base',
   file: 'file',
   'custom-tool': 'custom tool',
+  'custom-block': 'custom block',
   skill: 'skill',
   'mcp-server': 'MCP server',
   credential: 'credential',
@@ -97,5 +98,10 @@ export function forkBlockerResolution(
       return `deleted in the source — map it to an existing ${FORK_RESOURCE_KIND_LABEL[ref.kind] ?? 'resource'} in ${targetWorkspaceName}`
     case 'workflow-missing':
       return `deploy "${ref.sourceLabel}" in the source or remove the reference`
+    // Phrased as a consequence, not a loss: an unmapped custom block does not empty a field,
+    // it keeps invoking the SOURCE environment's block. The row renders this as the whole
+    // clause after the block name (no "would lose" lead-in), so it reads as a sentence.
+    case 'unmapped-custom-block':
+      return `still runs the source's block — map it to a custom block published in ${targetWorkspaceName}`
   }
 }