fix: surface SMTP failures from gmail share endpoint to UI

[mengw15]

What changes were proposed in this PR?

GmailResource.sendEmailRequest discarded the Either[String, Unit] returned by sendEmail. The endpoint itself was typed Unit, so JAX-RS responded 204 No Content regardless of outcome — any SMTP failure (invalid credentials, network error, etc.) was logged server-side but the HTTP layer reported success, and the frontend's next: callback fired a green "Email sent successfully" toast even though no mail was delivered.

This PR closes that gap in two layers:

Backend (GmailResource.scala) — pattern-match the Either and throw WebApplicationException(error, Response.Status.BAD_GATEWAY) on Left. JAX-RS converts the exception into an HTTP 502, which triggers Angular's error: callback on the frontend side. This matches the existing codebase convention in AdminUserResource (Email already exists, 409) and UserResource (User not found, 404).

Frontend (gmail.service.ts) — the existing error: branch only console.error'd. Add a notificationService.error(...) call mirroring the existing notifyUnauthorizedLogin error handler in the same file (lines 56–61). The user-facing toast uses a generic message ("Failed to send email. Please try again or contact admin.") rather than the raw SMTP error, to avoid exposing protocol-level details like 535-5.7.8 Username and Password not accepted to end users; the specific SMTP error continues to land in the backend log and the browser console for debugging.

Any related issues, documentation, discussions?

Closes #5161.

How was this PR tested?

Added gmail.service.spec.ts (Vitest + HttpClientTestingModule) covering both contracts:

• HTTP 2xx → notificationService.success("Email sent successfully") fires
• HTTP 502 → notificationService.error("Failed to send email. ...") fires

No backend test added: GmailResource has no JAX-RS controller test harness, and building one would require refactoring sendEmail out of the companion object into an injectable dependency — disproportionate to a five-line fix.

Verified locally:

• sbt "WorkflowExecutionService/scalafmtCheck" "WorkflowExecutionService/compile" — clean.
• yarn test --include='**/gmail.service.spec.ts' — 2 passed.
• yarn prettier --check src/app/common/service/gmail/gmail.service.spec.ts — clean.

Manual verification path (for reviewers reproducing the issue's repro):

1. Don't set USER_SYS_GOOGLE_SMTP_GMAIL / USER_SYS_GOOGLE_SMTP_PASSWORD.
2. Start amber backend + frontend.
3. Open the share dialog on any workflow/dataset/project, enter a real email, submit.
4. Frontend: red toast "Failed to send email. Please try again or contact admin.".
5. Backend log: Failed to send email: 535-5.7.8 Username and Password not accepted... (unchanged).
6. Browser console: Send email error: ... (the specific SMTP error).

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (claude-opus-4-7)

[codecov-commenter]

Codecov Report

❌ Patch coverage is 62.50000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 43.72%. Comparing base (0f5f791) to head (b0346e4).

Files with missing lines	Patch %	Lines
...org/apache/texera/web/resource/GmailResource.scala	50.00%	0 Missing and 3 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #5164      +/-   ##
============================================
+ Coverage     43.66%   43.72%   +0.05%     
  Complexity     2218     2218              
============================================
  Files          1049     1049              
  Lines         40580    40586       +6     
  Branches       4324     4327       +3     
============================================
+ Hits          17719    17745      +26     
+ Misses        21766    21731      -35     
- Partials       1095     1110      +15     

Flag	Coverage Δ		*Carryforward flag
access-control-service	39.53% <ø> (ø)		Carriedforward from 0f5f791
agent-service	33.76% <ø> (ø)		Carriedforward from 0f5f791
amber	44.07% <50.00%> (+0.12%)	⬆️
computing-unit-managing-service	1.38% <ø> (ø)		Carriedforward from 0f5f791
config-service	19.35% <ø> (ø)		Carriedforward from 0f5f791
file-service	32.18% <ø> (ø)		Carriedforward from 0f5f791
frontend	35.18% <100.00%> (+0.02%)	⬆️
python	90.50% <ø> (ø)		Carriedforward from 0f5f791
workflow-compiling-service	58.39% <ø> (ø)		Carriedforward from 0f5f791

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Yicong-Huang]

let's add tests to cover changes! need to have backend tests

[Copilot]

Pull request overview

This PR ensures SMTP/send failures from the /gmail/send backend endpoint are surfaced as HTTP errors so the Angular UI can display an error toast instead of falsely reporting success.

Changes:

• Backend: handle sendEmail’s Either result and translate failures into an HTTP 502 response.
• Frontend: show a user-facing error notification on failed /gmail/send requests (and log details to console).
• Frontend tests: add a Vitest spec covering both success (2xx) and failure (502) toast behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
amber/src/main/scala/org/apache/texera/web/resource/GmailResource.scala	Maps sendEmail failures to HTTP errors (502) instead of always returning 204.
frontend/src/app/common/service/gmail/gmail.service.ts	Adds an error toast in the HTTP error callback for send email requests.
frontend/src/app/common/service/gmail/gmail.service.spec.ts	Adds unit tests validating success/error notifications for the send email request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.