fix: ignore html tags while resolving

[khalatevarun]

Summary

Brief description of what this PR does and why.

Fixes #1406

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

How has this been tested? What should reviewers focus on?

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)

Screenshots/Videos

[vercel]

@khalatevarun is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR addresses a bug where HTML tags in user function code were being incorrectly parsed as workflow variables by the resolveTagVariables function. The system was treating HTML tags like <div> as workflow variable references (which use <tag> syntax), causing errors such as 'Block "div" was not found' when users included HTML strings in their code.

The fix introduces a comprehensive list of HTML tag names and adds filtering logic to distinguish between legitimate HTML content and actual workflow variables. This change is made to the apps/sim/app/api/function/execute/route.ts file, which appears to be part of the API execution pipeline for user-defined functions. The modification ensures that the template variable resolution system only processes genuine workflow variables while ignoring standard HTML markup.

This change integrates with the existing workflow system by maintaining the current variable resolution functionality while adding a preprocessing step to filter out HTML tags. The fix is scoped to the function execution API endpoint, which is appropriate since this is where user code containing HTML strings would be processed.

PR Description Notes:

• The Summary section lacks a proper description and only contains placeholder text
• The Testing section is empty and should describe how the fix was validated
• Several checklist items are not completed (style guidelines, tests)

Confidence score: 2/5

• This PR addresses a legitimate bug but has several concerning gaps in testing and documentation
• Score lowered due to incomplete PR template, missing tests, and potential edge cases in HTML tag detection logic
• Pay close attention to the HTML tag filtering implementation and ensure comprehensive testing is added before merge

_{1 file reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}

[khalatevarun]

Hi @icecrasher321, @waleedlatif1 would like to know your thoughts on this approach. This can be a temporary fix but it needs to be thought through.

I can start working on adding test cases if the approach seems viable for now.

[waleedlatif1]

@khalatevarun we have resolved this by only resolving blocks that have valid corresponding block names. in the UI, if we are going to try and resolve the value at runtime, it will be blue. otherwise, it will just be normal text and we will take it as-is without trying to resolve it