fix: support formatter functions in ECharts code blocks

[octo-patch]

Fixes #6536

Problem

When an ECharts configuration contains formatter (or other function-valued properties), json5.parse() throws a SyntaxError because function literals are not valid JSON5. The error is silently caught, option becomes undefined, and setOption({}) is called — the chart renders as a blank white box with no error shown.

Solution

Add a fallback parser that evaluates the ECharts config as a JavaScript expression using the Function constructor. This allows formatter callbacks and other JS function values to work correctly.

• json5.parse() is still tried first (safer, handles comments/trailing commas)
• Only if that fails, the Function constructor fallback is used
• The buildOption helper is extracted to avoid duplication between the two paths

Testing

Using an ECharts code block with a formatter function (as in the issue report) now renders the chart correctly instead of showing a blank box.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

octo-patch seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

octo-patch seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

✅ Build Successful - Preview code-sandbox Image for this PR:

registry.cn-hangzhou.aliyuncs.com/fastgpt/fastgpt-pr:code-sandbox_550219c5469555d59cc3c7bbbd23f5fccb2c162a

[github-actions]

✅ Build Successful - Preview fastgpt Image for this PR:

registry.cn-hangzhou.aliyuncs.com/fastgpt/fastgpt-pr:fastgpt_550219c5469555d59cc3c7bbbd23f5fccb2c162a

[github-actions]

✅ Build Successful - Preview mcp_server Image for this PR:

registry.cn-hangzhou.aliyuncs.com/fastgpt/fastgpt-pr:mcp_server_550219c5469555d59cc3c7bbbd23f5fccb2c162a

[c121914yu]

Please confirm whether there is a risk of injection attacks in this approach.

[octo-patch]

@c121914yu Yes — new Function(...) is eval-equivalent and runs in the page's JS context with access to window/cookies/etc. The current json5.parse() path is safe (no code exec), so this fallback strictly weakens the security posture.

The practical risk depends on the trust model for ECharts code-block content:

• LLM-only authored → low risk in practice
• User-pasted / shared / plugin-provided → high risk (attacker-controlled JS in the victim's browser)

If you'd prefer a safer fix, I can switch to one of:

1. AST guard — accept only function (...) { return ... } shapes and reject calls to global identifiers (window, fetch, eval, XMLHttpRequest, etc.). Covers the common formatter use cases without giving up the eval surface.
2. Iframe sandbox — render the chart inside sandbox="allow-scripts" (no allow-same-origin), so even if eval runs hostile code it can't reach parent cookies/storage.
3. Whitelist DSL — replace function support with a tiny ${value} / ${name} template syntax compiled at parse time, never evaluating user-provided code.

Happy to update the PR to whichever direction you prefer, or close it if you'd rather not widen the surface at all. My preference would be option 1 (AST guard) — it covers most formatter callbacks people write while keeping the dangerous eval features off-limits. Let me know which way you'd like to go.