Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/web/modules/ee/analysis/charts/components/chart-dropdown-menu.tsx`:
- Around line 41-65: The effect using getDashboardsAction inside useEffect
(guarded by isAddToDashboardDialogOpen) currently only handles resolved results
and will leave rejections unhandled; update the call to getDashboardsAction({
workspaceId }) (in the useEffect) to attach a .catch(...) to handle rejected
promises, checking the cancelled flag before calling side effects, and call
toast.error(getFormattedErrorMessage(error)) for failures; keep the existing
success branch that calls setDashboards(result.data.map(...)) and ensure the
cleanup still sets cancelled = true.
- Around line 113-133: The try block around addChartToDashboardAction needs a
catch to handle cases where the action throws (not just returns a falsy result);
wrap the await addChartToDashboardAction call with a catch that logs or captures
the error and calls toast.error(getFormattedErrorMessage(error) ||
t("workspace.analysis.charts.failed_to_add_chart_to_dashboard")), ensure you
still reset UI state as appropriate (e.g., keep setIsAddingToDashboard(false) in
finally), and avoid leaving the dialog open or selectedDashboardId set when the
call fails (consider closing the dialog or clearing selectedDashboardId in the
error path if intended); reference addChartToDashboardAction,
setIsAddingToDashboard, setIsAddToDashboardDialogOpen, setSelectedDashboardId,
and router.refresh when implementing the catch/failure handling.

In `@apps/web/modules/ee/analysis/charts/components/create-chart-view.tsx`:
- Line 110: The current chartType fallback uses DEFAULT_CHART_TYPE when
selectedChartType is undefined in edit mode; change the fallback order so in
edit mode you first use the persisted chart's type (the loaded chart object’s
type — e.g., chart?.type or loadedChart.type) before falling back to
DEFAULT_CHART_TYPE; update the assignment of chartType (and the similar logic
around lines 168-183) to: selectedChartType ?? (isEditing ? persistedChartType :
DEFAULT_CHART_TYPE) so the editor preserves the existing chart type when
editing.

In `@apps/web/modules/ee/analysis/charts/hooks/use-chart-dialog.ts`:
- Around line 221-234: The auto-add branch (when autoAddToDashboardId &&
savedChartId) currently returns early on addChartToDashboardAction failure and
leaves the newly created chart orphaned; update that branch to perform the same
cleanup as handleAddToDashboard: call the chart deletion/cleanup routine (e.g.,
deleteChartAction or the existing cleanup function used by handleAddToDashboard)
for savedChartId before returning, and include error logging/toast as before;
ensure you reference addChartToDashboardAction, savedChartId and
autoAddToDashboardId and mirror the cleanup logic from handleAddToDashboard so
the newly created chart is removed on failure to add to the dashboard.

In `@apps/web/modules/ee/analysis/lib/feedback-records.ts`:
- Line 1: The file begins with a no-op string literal "server-only"; replace
that literal with an actual import of the "server-only" module at the top of
apps/web/modules/ee/analysis/lib/feedback-records.ts so Next.js enforces the
server boundary; ensure the import is the first statement in the module (before
any other imports or code) so server-only enforcement triggers correctly.

---

Outside diff comments:
In `@apps/web/modules/ee/analysis/charts/hooks/use-chart-dialog.ts`:
- Around line 180-188: The updateChartAction call currently updates
name/type/query but omits persisting the selected directory; include the
selectedDirectoryId in the chartUpdateInput so edits save the new directory.
Specifically, in the updateChartAction(...) invocation (the chartUpdateInput
object used with updateChartAction, currentChartId, workspaceId, and chartData),
add selectedDirectoryId: chartData.selectedDirectoryId (or the appropriate
feedbackRecordDirectoryId property from chartData) so the saved chart reflects
the user's chosen directory.

In
`@apps/web/modules/ee/analysis/dashboards/components/dashboard-detail-client.tsx`:
- Line 163: The dashboard uses draftWidgets (const widgets = draftWidgets ??
dashboard.widgets) which masks refreshed server-side changes after a chart save;
after the chart save success handler calls router.refresh(), update the draft
state in that onSuccess path by either patching the matching draft widget (find
by widget.id/widget.visualizationId and update its title/query) or by clearing
and rehydrating draftWidgets from the newly refreshed dashboard.widgets while
preserving any layout edits (e.g., keep positions/sizes from draftWidgets but
replace content fields like name/query with dashboard.widgets values); implement
this logic in the chart save onSuccess handler so the UI reflects the refreshed
chart metadata immediately.