api_gemini 0.8.1

Gemini's API for accessing large language models (LLMs).
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

# Pattern: Error-Resilient

### Scope

- **Purpose**: Define the structural pattern for generation calls where all failure modes must degrade to a human-readable fallback string rather than propagating an error.
- **Responsibility**: Documents the Error-Resilient pattern — problem context, solution structure, applicability conditions, and consequences.
- **In Scope**: Generation calls inside UI-layer code, background formatting jobs, or any context where error propagation reaches an end user.
- **Out of Scope**: Library-internal code where error transparency is required; batch workloads where distinct failure accounting is needed.

### Problem

User-facing features cannot surface raw API errors. A generation failure must degrade gracefully to a human-readable placeholder rather than propagating an error or crashing.

### Solution

Wrap the generation call in a match that maps specific error variants (`RateLimitError`, `TimeoutError`, general failure) to distinct user-readable fallback strings. Client construction failure is handled before any network call is attempted. The function signature returns `String`, not `Result<String, Error>` — the error signal is absorbed at this boundary. See `docs/operation/002_usage_examples.md` for the underlying request construction procedure.

### Applicability

Use when:
- The caller cannot handle `Result` (for example, UI rendering code expecting `String`)
- Specific error conditions have distinct user-facing messages
- Latency spikes from rate limiting must be absorbed transparently

Avoid when:
- Transparency about error type is required by callers
- Callers need to distinguish between error variants for retry logic

### Consequences

- The caller always receives a string — no panics reach the UI layer
- Error signal is absorbed — callers cannot distinguish authentication failure from timeout
- Fallback messages must be meaningful to end users without exposing implementation details

### Sources

| File | Relationship |
|------|-------------|
| `src/models/api/content_generation/api_impl.rs` | `generate_content()` underlying this pattern |
| `src/error.rs` | Error variants matched in the fallback arms |

### Tests

| File | Relationship |
|------|-------------|
| `tests/inc/messages_api_test.rs` | Tests exercising the Error-Resilient path |

### Operations

| File | Relationship |
|------|-------------|
| `operation/002_usage_examples.md` | Underlying request construction procedure for this pattern |