@dbx-tools/appkit-mastra 0.1.112 → 0.3.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/src/chart.ts ADDED
@@ -0,0 +1,695 @@
1
+ /**
2
+ * Chart planner + chart cache.
3
+ *
4
+ * Self-contained chart subsystem with two layers:
5
+ *
6
+ * 1. Inner planner agent (private). Pure dataset-in /
7
+ * `EChartsOption`-out brain. Driven by {@link prepareChart};
8
+ * callers never instantiate it directly.
9
+ * 2. {@link prepareChart}: orchestration on top of the planner.
10
+ * Mints a `chartId`, caches an empty `{ chartId }` record
11
+ * synchronously, then resolves the dataset and runs the
12
+ * planner in the background. The terminal entry settles with
13
+ * either `result` (success) or `error` (failure). Both
14
+ * undefined means the entry is still processing.
15
+ *
16
+ * The cache surface ({@link fetchChart}) is the only state the
17
+ * HTTP route and the chart-producing tools share. `prepareChart`
18
+ * is dataset-agnostic - callers supply a `resolveData` callback
19
+ * that fetches the rows however they like (Genie statement, inline
20
+ * dataset, custom API). The module has no knowledge of Genie or
21
+ * statement ids; those concerns live in the tools that wrap it.
22
+ *
23
+ * Wire-format schemas live in `@dbx-tools/shared-mastra` so
24
+ * the demo client and any other UI consumer share the exact same
25
+ * shape this module reads and writes.
26
+ */
27
+
28
+ import { CacheManager } from "@databricks/appkit";
29
+ import { wire, type Chart, type ChartResult } from "@dbx-tools/shared-mastra";
30
+ import { Agent } from "@mastra/core/agent";
31
+ import type { RequestContext } from "@mastra/core/request-context";
32
+ import { createTool } from "@mastra/core/tools";
33
+ import { z } from "zod";
34
+
35
+ import type { MastraPluginConfig } from "./config";
36
+ import { buildModel } from "./model";
37
+ import { model } from "@dbx-tools/shared-model";
38
+ import { async, error, hash, log, string } from "@dbx-tools/shared-core";
39
+
40
+ const logger = log.logger("mastra/chart");
41
+
42
+ /* ------------------------------ constants ------------------------------ */
43
+
44
+ /**
45
+ * TTL for cached chart entries. One hour balances "long enough for
46
+ * the host UI to fetch the chart well after the model finished
47
+ * talking" against "short enough that abandoned chart ids don't
48
+ * pin storage". Matches the typical Databricks OBO token lifetime
49
+ * so any data re-resolution stays inside the original auth window.
50
+ */
51
+ const CHART_CACHE_TTL_SEC = 60 * 60;
52
+
53
+ /** Cache namespace; keeps the chart keyspace tidy. */
54
+ const CHART_CACHE_NAMESPACE = "mastra:chart";
55
+
56
+ /**
57
+ * `userKey` for `CacheManager.generateKey`. Chart ids are minted
58
+ * via `hash.id()` (v4 UUID) and are unguessable, so a
59
+ * constant user key is fine. The HTTP route can re-scope to the
60
+ * requesting user when policy demands it.
61
+ */
62
+ const CHART_CACHE_USER_KEY = "mastra-chart";
63
+
64
+ /** Default server-side long-poll budget for {@link fetchChart}. */
65
+ const DEFAULT_FETCH_TIMEOUT_MS = 60_000;
66
+
67
+ /** Default inter-poll sleep for {@link fetchChart}. */
68
+ const DEFAULT_FETCH_INTERVAL_MS = 250;
69
+
70
+ /* ------------------------------- schemas ------------------------------- */
71
+
72
+ /**
73
+ * One series data point. Wide variant set so the planner agent can
74
+ * faithfully pass through whatever the SQL row set contained
75
+ * (numbers, stringified numbers, nulls for missing measurements,
76
+ * `[x, y]` tuples for scatter, `{name, value}` slices for pie)
77
+ * without the structured-output guard rejecting the whole plan.
78
+ *
79
+ * Three layers of tolerance:
80
+ *
81
+ * 1. {@link z.preprocess} normalizes wire shapes BEFORE union
82
+ * dispatch: stringified numbers parse to numbers, finite
83
+ * checks reject `NaN` / `Infinity`, 2-element arrays coerce
84
+ * tuple components, and `{value}` objects with missing /
85
+ * stringified `value` get coerced or rejected uniformly.
86
+ * Anything not handleable becomes `null`.
87
+ * 2. The union accepts `null` as a first-class variant. Echarts
88
+ * renders null as a gap on bar / line / area (which is the
89
+ * right visual signal for "missing reading"). Scatter and
90
+ * pie filter nulls in {@link planToEchartsOption} because
91
+ * Echarts crashes on null tuples / slices.
92
+ * 3. {@link z.union#catch} backstops the whole thing: if
93
+ * preprocess somehow produces a shape that still doesn't
94
+ * match any variant, the bad item becomes `null` instead of
95
+ * taking down the entire chart with a
96
+ * `Structured output validation failed` error.
97
+ */
98
+ const chartDataPointSchema = z
99
+ .preprocess(
100
+ (v) => {
101
+ if (v === null || v === undefined) return null;
102
+ if (typeof v === "number") return Number.isFinite(v) ? v : null;
103
+ if (typeof v === "string") {
104
+ const n = Number(v);
105
+ return Number.isFinite(n) ? n : null;
106
+ }
107
+ if (Array.isArray(v) && v.length === 2) {
108
+ const x = typeof v[0] === "number" ? v[0] : Number(v[0]);
109
+ const y = typeof v[1] === "number" ? v[1] : Number(v[1]);
110
+ return Number.isFinite(x) && Number.isFinite(y) ? [x, y] : null;
111
+ }
112
+ if (typeof v === "object" && v !== null && "value" in v) {
113
+ const obj = v as { name?: unknown; value: unknown };
114
+ const val = typeof obj.value === "number" ? obj.value : Number(obj.value);
115
+ if (!Number.isFinite(val)) return null;
116
+ // Coerce numeric / boolean / nullish names to strings so a
117
+ // pie slice keyed on a year (`2024`) or category id is
118
+ // accepted without round-tripping through the catch arm.
119
+ const rawName = obj.name;
120
+ const name = typeof rawName === "string" ? rawName : rawName == null ? "" : String(rawName);
121
+ return { name, value: val };
122
+ }
123
+ return null;
124
+ },
125
+ z.union([
126
+ z.number(),
127
+ z.null(),
128
+ z.tuple([z.number(), z.number()]),
129
+ z.object({ name: z.string(), value: z.number() }),
130
+ ]),
131
+ )
132
+ .catch(null);
133
+
134
+ /**
135
+ * Compact, model-friendly representation of an Echarts spec. The
136
+ * planner agent emits this; {@link planToEchartsOption} expands it
137
+ * into a real `EChartsOption` JSON. Two layers because letting the
138
+ * model fill in a fully-typed `EChartsOption` is brittle (hundreds
139
+ * of optional fields, deep unions, version-dependent shapes). A
140
+ * small "chart plan" schema is much more reliable for a fast model
141
+ * and keeps animation / tooltip / styling defaults consistent
142
+ * across charts.
143
+ */
144
+ const chartPlanSchema = z.object({
145
+ chartType: wire.ChartTypeSchema,
146
+ title: z
147
+ .string()
148
+ .optional()
149
+ .describe(
150
+ string.toDescription(`
151
+ Short title shown above the chart. Optional; defaults to the
152
+ \`title\` argument the caller passed in.
153
+ `),
154
+ ),
155
+ xAxisLabel: z
156
+ .string()
157
+ .optional()
158
+ .describe(
159
+ string.toDescription(`
160
+ Axis label below the chart. Used for bar / line / area / scatter;
161
+ ignored for pie.
162
+ `),
163
+ ),
164
+ yAxisLabel: z
165
+ .string()
166
+ .optional()
167
+ .describe(
168
+ string.toDescription(`
169
+ Axis label to the left of the chart. Used for bar / line / area /
170
+ scatter; ignored for pie.
171
+ `),
172
+ ),
173
+ categories: z
174
+ .array(z.string())
175
+ .optional()
176
+ .describe(
177
+ string.toDescription(`
178
+ X-axis category labels for \`bar\` / \`line\` / \`area\` charts
179
+ (one per data point in each series). Omit for \`scatter\` (uses
180
+ [x, y] tuples) and \`pie\` (each slice carries its own \`name\`).
181
+ `),
182
+ ),
183
+ series: z
184
+ .array(
185
+ z.object({
186
+ name: z.string().describe(
187
+ string.toDescription(`
188
+ Legend name for this series.
189
+ `),
190
+ ),
191
+ data: z.array(chartDataPointSchema).describe(
192
+ string.toDescription(`
193
+ Data points. For \`bar\` / \`line\` / \`area\`, an array of
194
+ numbers aligned to \`categories\`. For \`scatter\`, an array
195
+ of \`[x, y]\` numeric tuples. For \`pie\`, an array of
196
+ \`{name, value}\` objects.
197
+ `),
198
+ ),
199
+ }),
200
+ )
201
+ .min(1)
202
+ .describe(
203
+ string.toDescription(`
204
+ One or more series to plot. Pie charts use exactly one series;
205
+ bar/line/area can stack multiple series sharing the same
206
+ \`categories\` axis.
207
+ `),
208
+ ),
209
+ });
210
+
211
+ type ChartPlan = z.infer<typeof chartPlanSchema>;
212
+
213
+ /**
214
+ * Canonical planner input shape. Tools that source rows from an
215
+ * inline dataset (`render_data`) use it as their `inputSchema`
216
+ * verbatim; tools that resolve rows from a remote (`prepare_chart`
217
+ * over a Genie statement) `omit({ data })` and `extend` with their
218
+ * own identifier field, so the field-level `.describe()` text
219
+ * stays a single source of truth. Server-only - the UI never
220
+ * sees a planner request, only the resolved {@link Chart}.
221
+ */
222
+ export const chartPlannerRequestSchema = z.object({
223
+ title: z.string().describe(
224
+ string.toDescription(`
225
+ Concise title shown above the chart (e.g. "Top 10 SKUs by Revenue").
226
+ `),
227
+ ),
228
+ description: z
229
+ .string()
230
+ .optional()
231
+ .describe(
232
+ string.toDescription(`
233
+ One-line intent the chart-planner uses when picking a chart type
234
+ and axis encodings (e.g. "compare quarterly revenue across
235
+ regions", "highlight the steep drop after position 5"). Not shown
236
+ to the user.
237
+ `),
238
+ ),
239
+ data: z
240
+ .array(z.record(z.string(), z.unknown()))
241
+ .nonempty("Data must contain at least one row")
242
+ .readonly()
243
+ .describe(
244
+ string.toDescription(`
245
+ Tabular dataset to chart. One object per row, keyed by column
246
+ name. Values may be strings, numbers, booleans, or null. The
247
+ chart-planner decides which columns are categories vs. numeric
248
+ series. Cap at a few hundred rows for legibility; sample /
249
+ aggregate larger datasets first.
250
+ `),
251
+ ),
252
+ });
253
+
254
+ export type ChartPlannerRequest = z.infer<typeof chartPlannerRequestSchema>;
255
+
256
+ /* --------------------------- planner instructions --------------------------- */
257
+
258
+ /**
259
+ * Format {@link wire.ChartTypeSchema}'s variants as a single
260
+ * human-friendly string of `` `<value>` for <description> ``
261
+ * clauses joined by semicolons, drawn from each variant's own
262
+ * `.describe()` so the planner prompt stays in lock-step with
263
+ * the schema by construction.
264
+ */
265
+ function formatChartTypePicker(): string {
266
+ return wire.ChartTypeSchema.options
267
+ .map((opt) => `\`${opt.value}\` for ${opt.description ?? ""}`)
268
+ .join("; ");
269
+ }
270
+
271
+ /**
272
+ * System prompt for the inner chart-planning agent. Tuned for a
273
+ * fast-tier model (Haiku, GPT-5-mini, Gemini Flash Lite).
274
+ */
275
+ const CHART_PLANNER_INSTRUCTIONS = string.toDescription(`
276
+ You design Apache Echarts visualizations. The user gives you a
277
+ tabular dataset (rows of objects) plus a title and an optional
278
+ description of the intent. You produce a small chart plan (chart
279
+ type, axis labels, categories, series) that best conveys the data.
280
+
281
+ Decision guide. Pick the chart type whose data shape matches the
282
+ dataset and the user's intent: ${formatChartTypePicker()}.
283
+
284
+ When in doubt between bar and line, prefer bar for unordered
285
+ categories and line for ordered ones (dates, time buckets, ranks).
286
+ Never pick pie for more than 7 slices.
287
+
288
+ For bar / line / area: pick one column as the category axis (usually
289
+ the only string-valued column) and one or more numeric columns as
290
+ series. Sort categories by the primary series value descending unless
291
+ the data is naturally ordered (dates, ranks).
292
+
293
+ For pie: pick the category column for slice names and one numeric
294
+ column for slice values. Emit a single series.
295
+
296
+ For scatter: pick two numeric columns and emit \`[x, y]\` tuples in a
297
+ single series.
298
+
299
+ Keep series names human-readable (use the column name; title case it
300
+ lightly if needed). Keep titles concise; do not repeat the user's
301
+ title in xAxisLabel / yAxisLabel.
302
+ `);
303
+
304
+ /* ----------------------------- planner agent ----------------------------- */
305
+
306
+ /**
307
+ * One planner `Agent` per plugin config. Cached on config object
308
+ * identity so callers can `prepareChart({ config, ... })` from a
309
+ * hot path without paying the Agent-constructor cost every call.
310
+ * `WeakMap` lets retired configs (e.g. test reconfigurations)
311
+ * release their agent without manual eviction.
312
+ */
313
+ const plannerAgents = new WeakMap<MastraPluginConfig, Agent>();
314
+
315
+ function getPlannerAgent(config: MastraPluginConfig): Agent {
316
+ let agent = plannerAgents.get(config);
317
+ if (!agent) {
318
+ agent = new Agent({
319
+ id: "chart_planner",
320
+ name: "Chart Planner",
321
+ description: "Picks chart type and axis encodings for a dataset.",
322
+ instructions: CHART_PLANNER_INSTRUCTIONS,
323
+ model: ({ requestContext }) =>
324
+ buildModel(config, requestContext, { modelClass: model.ModelClass.ChatFast }),
325
+ });
326
+ plannerAgents.set(config, agent);
327
+ }
328
+ return agent;
329
+ }
330
+
331
+ /**
332
+ * Run the planner against `request` and return the resolved
333
+ * Echarts spec. Throws on planner failure - {@link prepareChart}
334
+ * catches and stashes the error in the cache entry.
335
+ */
336
+ async function runChartPlanner(
337
+ config: MastraPluginConfig,
338
+ request: ChartPlannerRequest,
339
+ options: { requestContext?: RequestContext; abortSignal?: AbortSignal } = {},
340
+ ): Promise<ChartResult> {
341
+ const { title, description, data } = request;
342
+ const { requestContext, abortSignal } = options;
343
+ const prompt = string.toDescription({
344
+ Title: title,
345
+ ...(description ? { Description: description } : {}),
346
+ "Dataset (JSON, one row per object)": JSON.stringify(data, null, 2),
347
+ });
348
+ const result = await getPlannerAgent(config).generate(prompt, {
349
+ structuredOutput: { schema: chartPlanSchema },
350
+ ...(requestContext ? { requestContext } : {}),
351
+ ...(abortSignal ? { abortSignal } : {}),
352
+ });
353
+ const plan = chartPlanSchema.parse(result.object);
354
+ const option = planToEchartsOption(plan, title);
355
+ return { chartType: plan.chartType, option };
356
+ }
357
+
358
+ /* ------------------------------ cache helpers ------------------------------ */
359
+
360
+ /** Build the canonical cache key for a `chartId`. */
361
+ async function chartCacheKey(chartId: string): Promise<string> {
362
+ return (await CacheManager.getInstance()).generateKey(
363
+ [CHART_CACHE_NAMESPACE, chartId],
364
+ CHART_CACHE_USER_KEY,
365
+ );
366
+ }
367
+
368
+ /**
369
+ * Persist a {@link Chart} entry under its `chartId`. Refreshes
370
+ * the TTL on every write. Cache-layer failures are logged and
371
+ * swallowed so background runners never throw into the
372
+ * unhandled-rejection stream.
373
+ */
374
+ async function writeChart(entry: Chart): Promise<void> {
375
+ try {
376
+ const key = await chartCacheKey(entry.chartId);
377
+ await CacheManager.getInstanceSync().set(key, entry, {
378
+ ttl: CHART_CACHE_TTL_SEC,
379
+ });
380
+ } catch (err) {
381
+ logger.warn("write-error", {
382
+ chartId: entry.chartId,
383
+ error: error.errorMessage(err),
384
+ });
385
+ }
386
+ }
387
+
388
+ /**
389
+ * Look up a chart by id. Returns `undefined` on miss, on
390
+ * expiry, or when the cache layer is unhealthy - never throws.
391
+ */
392
+ async function readChart(chartId: string): Promise<Chart | undefined> {
393
+ try {
394
+ const key = await chartCacheKey(chartId);
395
+ const v = await CacheManager.getInstanceSync().get<Chart>(key);
396
+ return v ?? undefined;
397
+ } catch (err) {
398
+ logger.warn("read-error", {
399
+ chartId,
400
+ error: error.errorMessage(err),
401
+ });
402
+ return undefined;
403
+ }
404
+ }
405
+
406
+ /* --------------------------- prepareChart orchestrator --------------------------- */
407
+
408
+ /** Inputs to {@link prepareChart}. */
409
+ export interface PrepareChartOptions {
410
+ /** Plugin config; resolves the planner agent's model. */
411
+ config: MastraPluginConfig;
412
+ /** Display title forwarded to the planner agent. */
413
+ title?: string;
414
+ /** Optional intent hint forwarded to the planner agent. */
415
+ description?: string;
416
+ /**
417
+ * Resolves the rows to chart. Called once, in the background.
418
+ * Any thrown error lands in the cache as the entry's `error`
419
+ * field (never propagated to the caller of {@link prepareChart}).
420
+ * An empty `rows` array is rejected as `"dataset has no rows;
421
+ * nothing to chart"`.
422
+ */
423
+ resolveData: (signal?: AbortSignal) => Promise<{ rows: ReadonlyArray<Record<string, unknown>> }>;
424
+ /**
425
+ * Per-request `RequestContext`. Forwarded to the planner agent so
426
+ * user-scoped model resolution (OBO) stays in effect.
427
+ */
428
+ requestContext?: RequestContext;
429
+ /**
430
+ * Cooperative cancellation. Forwarded to `resolveData` and the
431
+ * planner agent. Note: the chart task continues running in the
432
+ * background after the parent request ends, so external abort
433
+ * signals are best-effort; typical use is to leave this unset
434
+ * and let the 1h TTL cap stale entries.
435
+ */
436
+ signal?: AbortSignal;
437
+ }
438
+
439
+ /**
440
+ * Mint a `chartId`, cache an empty `{ chartId }` placeholder
441
+ * synchronously, and kick off a background task that resolves the
442
+ * dataset and runs the planner. Returns the `chartId` once the
443
+ * placeholder lands so the first {@link fetchChart} call always
444
+ * sees an entry (no spurious 404 race).
445
+ *
446
+ * The background task swallows its own failures and writes them
447
+ * as `error` entries, so callers never see a rejected promise.
448
+ * Cache state machine:
449
+ *
450
+ * - just after this call returns: `{ chartId }` (processing)
451
+ * - on planner success: `{ chartId, result }`
452
+ * - on data / planner failure: `{ chartId, error }`
453
+ */
454
+ export async function prepareChart(opts: PrepareChartOptions): Promise<{ chartId: string }> {
455
+ const chartId = hash.id();
456
+ await writeChart({ chartId });
457
+ logger.debug("queued", { chartId });
458
+ // Fire-and-forget. Failures land in the cache as `error` entries;
459
+ // never escape into an unhandled rejection.
460
+ void runPrepareChart(chartId, opts);
461
+ return { chartId };
462
+ }
463
+
464
+ async function runPrepareChart(chartId: string, opts: PrepareChartOptions): Promise<void> {
465
+ const startedAt = Date.now();
466
+ try {
467
+ const data = await opts.resolveData(opts.signal);
468
+ if (data.rows.length === 0) {
469
+ throw new Error("dataset has no rows; nothing to chart");
470
+ }
471
+ const result = await runChartPlanner(
472
+ opts.config,
473
+ {
474
+ title: opts.title ?? "Chart",
475
+ ...(opts.description ? { description: opts.description } : {}),
476
+ data: data.rows as ChartPlannerRequest["data"],
477
+ },
478
+ {
479
+ ...(opts.requestContext ? { requestContext: opts.requestContext } : {}),
480
+ ...(opts.signal ? { abortSignal: opts.signal } : {}),
481
+ },
482
+ );
483
+ await writeChart({ chartId, result });
484
+ logger.info("done", {
485
+ chartId,
486
+ chartType: result.chartType,
487
+ elapsedMs: Date.now() - startedAt,
488
+ });
489
+ } catch (err) {
490
+ const errText = error.errorMessage(err);
491
+ logger.warn("error", { chartId, error: errText });
492
+ await writeChart({ chartId, error: errText });
493
+ }
494
+ }
495
+
496
+ /* ------------------------------- long-poll fetch ------------------------------- */
497
+
498
+ /** Inputs to {@link fetchChart}. */
499
+ export interface FetchChartOptions {
500
+ /**
501
+ * Server-side polling budget in ms. When the entry stays in
502
+ * the processing state past this window, the helper returns the
503
+ * last seen value (still processing) so the client can re-poll.
504
+ * Defaults to {@link DEFAULT_FETCH_TIMEOUT_MS} (60s).
505
+ */
506
+ timeoutMs?: number;
507
+ /**
508
+ * Poll interval in ms. Defaults to
509
+ * {@link DEFAULT_FETCH_INTERVAL_MS} (250ms).
510
+ */
511
+ intervalMs?: number;
512
+ /** External cancellation handle (e.g. request `req.signal`). */
513
+ signal?: AbortSignal;
514
+ }
515
+
516
+ /**
517
+ * Long-poll the chart cache until the entry settles (`result` or
518
+ * `error` set), the entry is missing, or the server-side timeout
519
+ * elapses.
520
+ *
521
+ * Returns:
522
+ * - the resolved {@link Chart} when it settled, errored, or
523
+ * stayed in processing past `timeoutMs` (so the client can
524
+ * re-poll);
525
+ * - `undefined` when the entry is missing or expired (the
526
+ * consumer should treat as 404).
527
+ *
528
+ * `signal` lets the caller cancel ahead of timeout (e.g. the HTTP
529
+ * request closed). Cancellation propagates to the inter-poll sleep
530
+ * so the helper returns immediately.
531
+ */
532
+ export async function fetchChart(
533
+ chartId: string,
534
+ options: FetchChartOptions = {},
535
+ ): Promise<Chart | undefined> {
536
+ const timeoutMs = options.timeoutMs ?? DEFAULT_FETCH_TIMEOUT_MS;
537
+ const intervalMs = options.intervalMs ?? DEFAULT_FETCH_INTERVAL_MS;
538
+ const deadline = Date.now() + timeoutMs;
539
+
540
+ let last: Chart | undefined;
541
+ while (true) {
542
+ options.signal?.throwIfAborted();
543
+ last = await readChart(chartId);
544
+ if (!last) return undefined;
545
+ if (last.result !== undefined || last.error !== undefined) return last;
546
+ const remaining = deadline - Date.now();
547
+ if (remaining <= 0) return last;
548
+ await async.sleep(Math.min(intervalMs, remaining), options.signal);
549
+ }
550
+ }
551
+
552
+ /* ----------------------------- echarts expansion ----------------------------- */
553
+
554
+ /**
555
+ * Expand a {@link ChartPlan} into a full Echarts `EChartsOption`
556
+ * JSON. Centralized here so the planner agent only fills in the
557
+ * compact plan shape; tooltip / animation / color / grid defaults
558
+ * stay consistent across charts and are easy to tune without
559
+ * retraining model behaviour.
560
+ */
561
+ function planToEchartsOption(plan: ChartPlan, fallbackTitle: string): Record<string, unknown> {
562
+ const baseTitle = plan.title ?? fallbackTitle;
563
+ const grid = { left: 48, right: 24, top: 56, bottom: 48, containLabel: true };
564
+
565
+ if (plan.chartType === "pie") {
566
+ // Echarts crashes on null pie slices - filter them out.
567
+ // `{name, value}` slices are the only valid pie data shape,
568
+ // so drop bare numbers / tuples / nulls the planner may
569
+ // have leaked into a pie series.
570
+ const slices = (plan.series[0]?.data ?? []).filter(
571
+ (d): d is { name: string; value: number } =>
572
+ d !== null && typeof d === "object" && !Array.isArray(d),
573
+ );
574
+ return {
575
+ title: { text: baseTitle, left: "center" },
576
+ tooltip: { trigger: "item" },
577
+ legend: { bottom: 0 },
578
+ series: [
579
+ {
580
+ name: plan.series[0]?.name ?? baseTitle,
581
+ type: "pie",
582
+ radius: ["35%", "65%"],
583
+ data: slices,
584
+ },
585
+ ],
586
+ };
587
+ }
588
+
589
+ if (plan.chartType === "scatter") {
590
+ // Echarts crashes on null scatter points - keep only valid
591
+ // `[x, y]` tuples. Bare numbers / objects / nulls from a
592
+ // mismatched plan get dropped silently.
593
+ return {
594
+ title: { text: baseTitle, left: "center" },
595
+ tooltip: { trigger: "item" },
596
+ legend: { bottom: 0 },
597
+ grid,
598
+ xAxis: { type: "value", name: plan.xAxisLabel },
599
+ yAxis: { type: "value", name: plan.yAxisLabel },
600
+ series: plan.series.map((s) => ({
601
+ name: s.name,
602
+ type: "scatter",
603
+ data: s.data.filter((d): d is [number, number] => Array.isArray(d) && d.length === 2),
604
+ })),
605
+ };
606
+ }
607
+
608
+ // bar / line / area share the same axis layout.
609
+ const isArea = plan.chartType === "area";
610
+ const seriesType = plan.chartType === "bar" ? "bar" : "line";
611
+ return {
612
+ title: { text: baseTitle, left: "center" },
613
+ tooltip: { trigger: "axis" },
614
+ legend: { bottom: 0 },
615
+ grid,
616
+ xAxis: {
617
+ type: "category",
618
+ data: plan.categories ?? [],
619
+ name: plan.xAxisLabel,
620
+ },
621
+ yAxis: { type: "value", name: plan.yAxisLabel },
622
+ series: plan.series.map((s) => ({
623
+ name: s.name,
624
+ type: seriesType,
625
+ data: s.data,
626
+ smooth: seriesType === "line",
627
+ ...(isArea ? { areaStyle: {} } : {}),
628
+ })),
629
+ };
630
+ }
631
+
632
+ /* ----------------------------- render_data tool ----------------------------- */
633
+
634
+ /**
635
+ * Build the `render_data` Mastra tool bound to the given plugin
636
+ * config. Auto-wired as a system tool on every agent (see
637
+ * `agents.ts`); per-agent tools can shadow it by registering a
638
+ * same-named entry.
639
+ *
640
+ * Thin wrapper over {@link prepareChart} for callers that already
641
+ * have a dataset in hand. Mints a `chartId` synchronously, caches
642
+ * an empty placeholder, and kicks off the chart-planner in the
643
+ * background. Returns just the `chartId`; the host UI resolves
644
+ * `[chart:<chartId>]` markers by hitting the plugin's
645
+ * `/embed/chart/:id` route.
646
+ *
647
+ * For Genie statement results, prefer the Genie agent's
648
+ * `prepare_chart` tool, which accepts a `statement_id` and
649
+ * resolves the rows lazily.
650
+ */
651
+ export function buildRenderDataTool(config: MastraPluginConfig) {
652
+ return createTool({
653
+ id: "render_data",
654
+ description: string.toDescription([
655
+ `
656
+ Submit a tabular dataset for inline rendering as a chart in
657
+ the user's view. Pass a title, the raw rows (array of objects
658
+ keyed by column name), and an optional one-line description
659
+ of the insight to highlight. Returns a short \`chartId\`;
660
+ the chart renders inline at the position you embed the
661
+ matching \`[chart:<chartId>]\` marker.
662
+ `,
663
+ `
664
+ Placement contract: embed \`[chart:<chartId>]\` on its own
665
+ line (blank lines above and below) wherever you want the
666
+ chart to appear in your reply. The chart resolves
667
+ asynchronously - the tool returns the id immediately and the
668
+ host UI fetches the chart from the cache once the planner
669
+ lands. You can call \`render_data\` multiple times in the
670
+ same turn (the tool is parallel-safe) and interleave the
671
+ markers with prose so each chart sits next to its
672
+ commentary.
673
+ `,
674
+ `
675
+ Use whenever a SQL row set, API response, or hand-built
676
+ dataset would land better as a picture than as a list or
677
+ table. Cap input at a few hundred rows; sample or aggregate
678
+ larger datasets first.
679
+ `,
680
+ ]),
681
+ inputSchema: chartPlannerRequestSchema,
682
+ outputSchema: wire.ChartSchema.pick({ chartId: true }),
683
+ execute: async (input, ctxRaw) => {
684
+ const { title, description, data } = input as ChartPlannerRequest;
685
+ const ctx = ctxRaw as { requestContext?: RequestContext } | undefined;
686
+ return prepareChart({
687
+ config,
688
+ title,
689
+ ...(description ? { description } : {}),
690
+ resolveData: () => Promise.resolve({ rows: data }),
691
+ ...(ctx?.requestContext ? { requestContext: ctx.requestContext } : {}),
692
+ });
693
+ },
694
+ });
695
+ }