Report 6.2 — Error Handling for Edge Cases 10 Points

This write-up covers how incomplete transcripts, API failures, and malformed LLM data are handled to earn the full 10 points for robustness.

Incomplete or Sparse Transcripts

When the transcript lacks details:

The controller still sends it to ActionItemExtractorService; if OpenAI returns empty text, OpenAIService retries with a reinforced prompt requesting concrete action items.
If the response still lacks structure, the extractor captures the raw string as a single action entry with a raw_output field so no request is dropped.
Reports indicate the total requested vs succeeded for visibility into gaps.

API Failures (OpenAI / HubSpot)

Every external call is wrapped in try/catch with logging:

OpenAI: Exceptions bubble up to be logged; fallback prompts run before giving up.
HubSpot: Each deal creation or deletion logs success/failure status. Failures increment counters and include error messages inside the reports.
Deletion still proceeds for remaining IDs even if one delete fails, maximizing cleanup.

Malformed Data

If OpenAI outputs JSON that cannot be parsed:

The extractor tries to clean code fences and parse again.
On persistent failure, raw JSON string remains to help operators refine prompts.
HubSpot creation gracefully handles missing fields by defaulting priority to NONE (treated as LOW) and leaving other values blank.

Visualization

See plantuml/behavior/uml_state_machine_diagram.html and uml_activity_diagram.html for fallback states that represent these error paths.

Monitoring & Alerting

Execution metadata (timestamps/duration) and the generated reports feed dashboards or logs so teams can detect repeated failures quickly.

Retries, logging, and structural fallbacks ensure incomplete transcripts or downstream outages don't crash the service, satisfying the 10-point criteria.