frontend/src/app/components/edit-database-schema/edit-database-schema.component.ts (1)

232-246: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

rejectBatch failure leaves UI in inconsistent state.

If rejectBatch throws, the await completes but the subsequent messages.update() still runs, clearing batchId and removing the preview diagram despite the rejection not being persisted on the backend. Consider wrapping in try/catch to preserve state on failure.

Proposed fix

 async onReject() {
   const batch = this.pendingBatch();
   if (!batch?.batchId) return;

-  await this._tableSchema.rejectBatch(batch.batchId);
-  this.messages.update((msgs) =>
-    msgs
-      .filter((m) => !(m.role === 'diagram' && m.text === 'Schema Preview'))
-      .map((m) => (m === batch ? { ...m, batchId: undefined } : m))
-      .concat({
-        role: 'ai',
-        text: 'Changes rejected. Feel free to describe what you need differently.',
-      }),
-  );
+  try {
+    await this._tableSchema.rejectBatch(batch.batchId);
+    this.messages.update((msgs) =>
+      msgs
+        .filter((m) => !(m.role === 'diagram' && m.text === 'Schema Preview'))
+        .map((m) => (m === batch ? { ...m, batchId: undefined } : m))
+        .concat({
+          role: 'ai',
+          text: 'Changes rejected. Feel free to describe what you need differently.',
+        }),
+    );
+  } catch (err: unknown) {
+    const error = err as { error?: { message?: string }; message?: string };
+    this.messages.update((msgs) => [
+      ...msgs,
+      {
+        role: 'error',
+        text: error?.error?.message || error?.message || 'Failed to reject changes.',
+      },
+    ]);
+  }
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@frontend/src/app/components/edit-database-schema/edit-database-schema.component.ts`
around lines 232 - 246, The onReject handler currently calls await
this._tableSchema.rejectBatch(batch.batchId) but always runs messages.update
afterwards, which can clear batchId and remove the preview even if the backend
call fails; modify onReject (use pendingBatch() to get the batch) to wrap the
rejectBatch call in a try/catch and only perform messages.update when
rejectBatch succeeds, and in the catch preserve the existing messages state and
surface the error (e.g., log or show a user notification) so the UI remains
consistent if _tableSchema.rejectBatch throws.