Skip to content

fix(search): match block references by the name the canvas shows - #6779

Merged
icecrasher321 merged 2 commits into
stagingfrom
fix/workflow-search-block-name-spaces
Aug 17, 2026
Merged

fix(search): match block references by the name the canvas shows#6779
icecrasher321 merged 2 commits into
stagingfrom
fix/workflow-search-block-name-spaces

Conversation

@icecrasher321

Copy link
Copy Markdown
Collaborator

Summary

  • Cmd+F in the workflow editor couldn't find a block reference by the name shown on the card. A reference stores its target as the block's normalized name — lowercased, whitespace and dots stripped — so a block titled Send Email is written <sendemail.content>, and the reference's searchable text never contained the block's actual name.
  • Searching Send Email found the block card and zero references; searching sendemail found the references and zero block cards. No single query found both, and the run-together form is the one nothing in the UI ever shows.
  • A reference's prefix now resolves back through the same helper that produced it (normalizeName), so references are searched under the name the block is titled with.
  • rawValue is untouched, so the stored form keeps matching and the highlight and replace paths, which key off it, are unaffected.
  • Environment references ({{KEY}}), system prefixes (loop, parallel, variable), and references left behind by a deleted block resolve to no name and stay exactly as written.

Type of Change

  • Bug fix

Testing

  • 122 search-replace tests pass, including 5 new ones covering the spaced name, the stored token, the resolved search text, unresolved prefixes, and environment references.
  • Verified the new tests are non-vacuous — stubbing the resolver out fails 3 of them.
  • bun run lint, bun run type-check, bun run check:audits (29 audits), and the block-registry check all pass.

Checklist

  • Code follows project style guidelines
  • Self-reviewed my changes
  • Tests added/updated and passing
  • No new warnings introduced
  • I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

A block reference stores its target as the block's normalized name -
lowercased with whitespace and dots stripped - so a block titled "Send Email"
is written `<sendemail.content>`. Workflow search indexed that token as-is, so
its searchable text never contained the block's actual name.

Searching a name the way it reads on the card therefore found the block itself
and none of its references, while the run-together form found the references
and not the block. No single query could find both, and the run-together form
is the one nothing in the UI ever shows.

Resolve a reference's prefix back through the same helper that produced it, so
the reference is searched under the name the block is titled with. `rawValue`
is untouched, so the stored form keeps matching and the highlight and replace
paths, which key off it, are unaffected.

Environment references, system prefixes like `loop`, and references left
behind by a deleted block resolve to no name and stay exactly as written.
@vercel

vercel Bot commented Aug 17, 2026

Copy link
Copy Markdown

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

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
docs Skipped Skipped Aug 17, 2026 7:53pm

Request Review

@cursor

cursor Bot commented Aug 17, 2026

Copy link
Copy Markdown

PR Summary

Low Risk
Search-indexing-only change with broad test coverage; no changes to stored reference tokens or replace behavior.

Overview
Workflow Cmd+F could not find inline block references when you searched the display name on the card (e.g. API 1), because references are stored as normalized tokens (<api1.output>) and indexing only used that token for searchText and query matching.

This PR maps normalized reference prefixes back to block titles via buildBlockNamesByReferencePrefix and resolveInlineReferenceSearchText, wired through indexWorkflowSearchMatches for subblock strings and tool-input params. Queries can match both the spaced title and the stored token; indexed searchText becomes names like API 1.output while rawValue stays unchanged for highlight/replace.

Legacy dot collisions (two blocks whose names normalize to the same prefix) follow the same rule as BlockResolver: the dot-free name wins. Environment refs, system prefixes (loop), and orphaned references are left as written.

Reviewed by Cursor Bugbot for commit 39c12a0. Configure here.

@greptile-apps

greptile-apps Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

The PR makes workflow references searchable by the target block name displayed on the canvas while preserving their stored token, range, and replacement behavior.

  • Builds a normalized reference-prefix-to-block-name index for each workflow.
  • Applies resolved block names to references in ordinary subblocks and tool inputs.
  • Adds coverage for displayed names, stored tokens, unresolved prefixes, environment references, and normalized-name collisions.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename Overview
apps/sim/lib/workflows/search-replace/resources/references.ts Adds reference-prefix indexing and display-name resolution while retaining unresolved and non-workflow reference text.
apps/sim/lib/workflows/search-replace/indexer.ts Uses resolved block names as searchable reference text across ordinary and tool-input values without changing raw replacement coordinates.
apps/sim/lib/workflows/search-replace/indexer.test.ts Adds focused regression tests for canvas-visible names, raw tokens, unresolved references, environment keys, and normalized-name collisions.

Reviews (2): Last reviewed commit: "fix(search): keep the dot-free name on a..." | Re-trigger Greptile

Comment thread apps/sim/lib/workflows/search-replace/resources/references.ts
…ision

Creating or renaming a block enforces uniqueness at the normalized level, but
legacy workflows can still hold two names that collide only now that
`normalizeName` strips dots. `BlockResolver` settles that tie by letting the
dot-free name keep ownership of the key, so previously working references never
change targets.

The prefix map took whichever block was iterated last instead, so search could
name a reference after the dotted block while execution resolved it to the
dot-free one - search reporting the wrong block, which is what this is meant to
stop. Mirror the resolver's rule so both agree.
@icecrasher321

Copy link
Copy Markdown
Collaborator Author

@greptile

@icecrasher321

Copy link
Copy Markdown
Collaborator Author

@cursor review

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

Reviewed by Cursor Bugbot for commit 39c12a0. Configure here.

@icecrasher321
icecrasher321 merged commit 5d172b4 into staging Aug 17, 2026
30 checks passed
@icecrasher321
icecrasher321 deleted the fix/workflow-search-block-name-spaces branch August 17, 2026 20:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant