More accurate handling of LLM errors

[DavidMStraub]

No description provided.

[Copilot]

Pull request overview

This PR improves how failures from the Pydantic AI agent / model provider are translated into HTTP errors, and adds regression tests to ensure specific exception types map to stable status codes.

Changes:

• Add targeted exception handling in answer_with_agent() to distinguish provider HTTP errors (502) from transport/API failures (504).
• Switch unexpected-error logging to logger.exception(...) for better traceback visibility.
• Add a new pytest suite validating the status-code mapping for common agent/provider failure modes.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
gramps_webapi/api/llm/__init__.py	Refines exception-to-HTTP-status mapping for LLM agent execution errors.
tests/test_llm_errors.py	Adds parametrized tests asserting the expected HTTP status codes for representative LLM/agent exceptions.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

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

Suppressed comments (1)

gramps_webapi/api/llm/init.py:203

• httpx.TransportError is broader than timeouts (it covers connect/protocol/other transport failures), but this handler maps all transport errors to HTTP 504 (gateway timeout). That will misclassify non-timeout upstream failures; consider catching httpx.TimeoutException separately for 504 and using a different status (e.g. 503) for other transport errors.

    except (ModelAPIError, httpx.TransportError) as e:
        # network failure or timeout talking to the provider
        logger.error("Model provider request failed: %r", e)
        abort_with_message(504, "The AI model did not respond. Please try again.")