@umituz/react-native-ai-gemini-provider 1.14.27 → 1.14.29
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/src/domain/README.md +232 -0
- package/src/domain/constants/README.md +191 -0
- package/src/domain/entities/README.md +238 -0
- package/src/infrastructure/README.md +252 -0
- package/src/infrastructure/cache/CACHE_SYSTEM.md +213 -0
- package/src/infrastructure/cache/README.md +213 -0
- package/src/infrastructure/content/CONTENT_BUILDER.md +175 -0
- package/src/infrastructure/content/README.md +175 -0
- package/src/infrastructure/interceptors/README.md +226 -0
- package/src/infrastructure/interceptors/REQUEST_INTERCEPTORS.md +171 -0
- package/src/infrastructure/job/JOB_MANAGER.md +174 -0
- package/src/infrastructure/job/README.md +194 -0
- package/src/infrastructure/response/README.md +187 -0
- package/src/infrastructure/response/RESPONSE_FORMATTER.md +185 -0
- package/src/infrastructure/services/CORE_CLIENT_SERVICE.md +202 -0
- package/src/infrastructure/services/FEATURE_MODEL_SELECTOR_SERVICE.md +206 -0
- package/src/infrastructure/services/GENERATION_EXECUTOR_SERVICE.md +176 -0
- package/src/infrastructure/services/IMAGE_EDIT_SERVICE.md +169 -0
- package/src/infrastructure/services/IMAGE_GENERATION_SERVICE.md +166 -0
- package/src/infrastructure/services/JOB_PROCESSOR_SERVICE.md +174 -0
- package/src/infrastructure/services/PROVIDER_INITIALIZER_SERVICE.md +176 -0
- package/src/infrastructure/services/README.md +233 -0
- package/src/infrastructure/services/RETRY_SERVICE.md +178 -0
- package/src/infrastructure/services/STREAMING_SERVICE.md +166 -0
- package/src/infrastructure/services/STRUCTURED_TEXT_SERVICE.md +175 -0
- package/src/infrastructure/services/TEXT_GENERATION_SERVICE.md +160 -0
- package/src/infrastructure/services/VEO_HTTP_CLIENT_SERVICE.md +179 -0
- package/src/infrastructure/services/VEO_POLLING_SERVICE.md +173 -0
- package/src/infrastructure/services/VIDEO_DOWNLOADER_SERVICE.md +166 -0
- package/src/infrastructure/services/VIDEO_ERROR_HANDLER_SERVICE.md +185 -0
- package/src/infrastructure/services/VIDEO_GENERATION_SERVICE.md +176 -0
- package/src/infrastructure/services/VIDEO_URL_EXTRACTOR_SERVICE.md +186 -0
- package/src/infrastructure/telemetry/README.md +203 -0
- package/src/infrastructure/telemetry/TELEMETRY_SYSTEM.md +200 -0
- package/src/infrastructure/utils/DATA_TRANSFORMER_UTILS.md +175 -0
- package/src/infrastructure/utils/ERROR_MAPPER.md +170 -0
- package/src/infrastructure/utils/ERROR_UTILITIES.md +208 -0
- package/src/infrastructure/utils/IMAGE_PREPARER_UTILS.md +185 -0
- package/src/infrastructure/utils/INPUT_BUILDERS.md +214 -0
- package/src/infrastructure/utils/MODEL_VALIDATION_UTILS.md +189 -0
- package/src/infrastructure/utils/PERFORMANCE_UTILITIES.md +477 -0
- package/src/infrastructure/utils/PERFORMANCE_UTILS.md +219 -0
- package/src/infrastructure/utils/README.md +289 -0
- package/src/presentation/README.md +187 -0
- package/src/presentation/hooks/README.md +188 -0
- package/src/presentation/hooks/USE_GEMINI_HOOK.md +226 -0
- package/src/providers/README.md +247 -0
|
@@ -0,0 +1,171 @@
|
|
|
1
|
+
# Request Interceptors
|
|
2
|
+
|
|
3
|
+
Middleware system for modifying AI requests before they're sent to the API. Allows applications to add custom logic, logging, authentication, and request transformation.
|
|
4
|
+
|
|
5
|
+
## 📍 Import Path
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
import { requestInterceptors } from '@umituz/react-native-ai-gemini-provider';
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
## 🎯 Purpose
|
|
12
|
+
|
|
13
|
+
Use request interceptors to modify API requests before sending. Provides middleware for authentication, logging, validation, caching, and data transformation.
|
|
14
|
+
|
|
15
|
+
**When to use:**
|
|
16
|
+
- Add authentication headers to requests
|
|
17
|
+
- Log and monitor API calls
|
|
18
|
+
- Transform request data
|
|
19
|
+
- Implement rate limiting
|
|
20
|
+
- Validate payloads
|
|
21
|
+
- Add custom headers
|
|
22
|
+
|
|
23
|
+
## 📌 Strategy
|
|
24
|
+
|
|
25
|
+
Interceptors provide clean separation of concerns. This system:
|
|
26
|
+
- Executes request interceptors in order
|
|
27
|
+
- Returns unsubscribe functions for cleanup
|
|
28
|
+
- Supports async interceptors
|
|
29
|
+
- Maintains immutability of context
|
|
30
|
+
- Enables composable middleware chains
|
|
31
|
+
|
|
32
|
+
**Key Decision**: Use interceptors for cross-cutting concerns. Keep business logic in services, use interceptors for operational concerns.
|
|
33
|
+
|
|
34
|
+
## ⚠️ Rules
|
|
35
|
+
|
|
36
|
+
### Usage Rules
|
|
37
|
+
- **MUST** return modified context from interceptors
|
|
38
|
+
- **SHOULD** handle errors in interceptors gracefully
|
|
39
|
+
- **MUST** unsubscribe from interceptors when done
|
|
40
|
+
- **SHOULD NOT** block execution excessively
|
|
41
|
+
- **MUST** maintain execution order dependency
|
|
42
|
+
|
|
43
|
+
### Request Interceptor Rules
|
|
44
|
+
- **MUST** return RequestContext object
|
|
45
|
+
- **SHOULD** validate inputs in interceptors
|
|
46
|
+
- **MUST NOT** mutate original context directly
|
|
47
|
+
- **SHOULD** handle async operations properly
|
|
48
|
+
- **MUST NOT** throw errors from interceptors
|
|
49
|
+
|
|
50
|
+
### Best Practices Rules
|
|
51
|
+
- **SHOULD** add logging interceptor first
|
|
52
|
+
- **MUST** clean up interceptors on unmount
|
|
53
|
+
- **SHOULD NOT** create circular dependencies
|
|
54
|
+
- **MUST** return new context objects
|
|
55
|
+
- **SHOULD** keep interceptors lightweight
|
|
56
|
+
|
|
57
|
+
## 🤖 AI Agent Guidelines
|
|
58
|
+
|
|
59
|
+
### When Adding Interceptors
|
|
60
|
+
1. **READ** existing interceptor patterns first
|
|
61
|
+
2. **UNDERSTAND** execution order (FIFO)
|
|
62
|
+
3. **IMPLEMENT** error handling
|
|
63
|
+
4. **RETURN** modified context
|
|
64
|
+
5. **TEST** interceptor in isolation
|
|
65
|
+
|
|
66
|
+
### When Removing Interceptors
|
|
67
|
+
1. **CALL** unsubscribe function
|
|
68
|
+
2. **VERIFY** no memory leaks
|
|
69
|
+
3. **UPDATE** dependent code
|
|
70
|
+
4. **TEST** after removal
|
|
71
|
+
5. **DOCUMENT** removal reason
|
|
72
|
+
|
|
73
|
+
### When Debugging Interceptors
|
|
74
|
+
1. **ADD** debug interceptor at start/end of chain
|
|
75
|
+
2. **LOG** context before/after modifications
|
|
76
|
+
3. **CHECK** execution order
|
|
77
|
+
4. **VERIFY** context immutability
|
|
78
|
+
5. **TEST** with various scenarios
|
|
79
|
+
|
|
80
|
+
### Code Style Rules
|
|
81
|
+
- **USE** async/await for async operations
|
|
82
|
+
- **RETURN** new context objects (spread operator)
|
|
83
|
+
- **HANDLE** errors with try-catch
|
|
84
|
+
- **LOG** important operations
|
|
85
|
+
- **COMMENT** complex transformation logic
|
|
86
|
+
|
|
87
|
+
## 📦 Available Class
|
|
88
|
+
|
|
89
|
+
### requestInterceptors
|
|
90
|
+
|
|
91
|
+
**Refer to**: [`RequestInterceptors.ts`](./RequestInterceptors.ts)
|
|
92
|
+
|
|
93
|
+
**Methods:**
|
|
94
|
+
- `use(interceptor)` - Add interceptor
|
|
95
|
+
- `apply(context)` - Apply all interceptors
|
|
96
|
+
- `clear()` - Clear all interceptors
|
|
97
|
+
- `count()` - Get interceptor count
|
|
98
|
+
|
|
99
|
+
**Execution Order:** First added runs first (FIFO)
|
|
100
|
+
|
|
101
|
+
## 🔗 Related Modules
|
|
102
|
+
|
|
103
|
+
- **Response Interceptors**: [`ResponseInterceptors.ts`](./ResponseInterceptors.ts)
|
|
104
|
+
- **Infrastructure README**: [`../infrastructure/README.md`](../infrastructure/README.md)
|
|
105
|
+
- **Services**: [`../services/README.md`](../services/README.md)
|
|
106
|
+
|
|
107
|
+
## 📋 Interceptor Patterns
|
|
108
|
+
|
|
109
|
+
### Authentication Pattern
|
|
110
|
+
1. Add interceptor before operations
|
|
111
|
+
2. Inject API key/token into context
|
|
112
|
+
3. Return modified context
|
|
113
|
+
4. Handle missing credentials
|
|
114
|
+
5. Clean up interceptor when done
|
|
115
|
+
|
|
116
|
+
### Logging Pattern
|
|
117
|
+
1. Add interceptor at start of chain
|
|
118
|
+
2. Log request/response details
|
|
119
|
+
3. Include timing information
|
|
120
|
+
4. Return context unchanged
|
|
121
|
+
5. Avoid logging sensitive data
|
|
122
|
+
|
|
123
|
+
### Transformation Pattern
|
|
124
|
+
1. Add interceptor for specific transformation
|
|
125
|
+
2. Extract data from context
|
|
126
|
+
3. Apply transformation logic
|
|
127
|
+
4. Return new context with transformed data
|
|
128
|
+
5. Handle transformation errors
|
|
129
|
+
|
|
130
|
+
## 🎓 Usage Patterns
|
|
131
|
+
|
|
132
|
+
### Request Interception
|
|
133
|
+
1. Import `requestInterceptors`
|
|
134
|
+
2. Call `use()` with interceptor function
|
|
135
|
+
3. Modify and return RequestContext
|
|
136
|
+
4. Store unsubscribe function
|
|
137
|
+
5. Call unsubscribe on cleanup
|
|
138
|
+
|
|
139
|
+
### Chained Interceptors
|
|
140
|
+
1. Add interceptors in desired order
|
|
141
|
+
2. Request: First added runs first
|
|
142
|
+
3. Store all unsubscribe functions
|
|
143
|
+
4. Clean up all on unmount
|
|
144
|
+
|
|
145
|
+
### Conditional Interceptors
|
|
146
|
+
1. Check environment/conditions
|
|
147
|
+
2. Add interceptor only if needed
|
|
148
|
+
3. Return early from interceptor if not applicable
|
|
149
|
+
4. Keep conditional logic simple
|
|
150
|
+
5. Test both conditional paths
|
|
151
|
+
|
|
152
|
+
## 🚨 Common Pitfalls
|
|
153
|
+
|
|
154
|
+
### Don't
|
|
155
|
+
- Mutate original context object
|
|
156
|
+
- Forget to unsubscribe from interceptors
|
|
157
|
+
- Block execution with heavy operations
|
|
158
|
+
- Throw errors from interceptors
|
|
159
|
+
- Create circular dependencies between interceptors
|
|
160
|
+
|
|
161
|
+
### Do
|
|
162
|
+
- Return new context objects
|
|
163
|
+
- Clean up interceptors when done
|
|
164
|
+
- Keep interceptors lightweight
|
|
165
|
+
- Handle errors gracefully
|
|
166
|
+
- Follow execution order rules
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
**Last Updated**: 2025-01-08
|
|
171
|
+
**See Also**: [AI_GUIDELINES.md](../../../../AI_GUIDELINES.md)
|
|
@@ -0,0 +1,174 @@
|
|
|
1
|
+
# Job Manager
|
|
2
|
+
|
|
3
|
+
Handles async job submission, tracking, and status management for AI generation tasks.
|
|
4
|
+
|
|
5
|
+
## 📍 Import Path
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
import { JobManager } from '@umituz/react-native-ai-gemini-provider';
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
## 🎯 Purpose
|
|
12
|
+
|
|
13
|
+
Use job manager to handle long-running AI operations asynchronously. Manages job lifecycle, status tracking, and result retrieval.
|
|
14
|
+
|
|
15
|
+
**When to use:**
|
|
16
|
+
- Submit long-running AI operations
|
|
17
|
+
- Track job status over time
|
|
18
|
+
- Implement polling for completion
|
|
19
|
+
- Manage async job lifecycles
|
|
20
|
+
- Retrieve results when ready
|
|
21
|
+
|
|
22
|
+
## 📌 Strategy
|
|
23
|
+
|
|
24
|
+
Job manager abstracts async operation complexity. This system:
|
|
25
|
+
- Generates unique job IDs
|
|
26
|
+
- Tracks job status through lifecycle
|
|
27
|
+
- Stores results for retrieval
|
|
28
|
+
- Handles errors gracefully
|
|
29
|
+
- Supports status polling
|
|
30
|
+
|
|
31
|
+
**Key Decision**: Use job manager for video generation and other long-running operations. Poll for status instead of blocking.
|
|
32
|
+
|
|
33
|
+
## ⚠️ Rules
|
|
34
|
+
|
|
35
|
+
### Usage Rules
|
|
36
|
+
- **MUST** save job ID after submission
|
|
37
|
+
- **SHOULD** check job status before getting result
|
|
38
|
+
- **MUST** handle job completion and failure
|
|
39
|
+
- **SHOULD** implement polling for long operations
|
|
40
|
+
- **MUST NOT** lose job IDs
|
|
41
|
+
|
|
42
|
+
### Job Lifecycle Rules
|
|
43
|
+
- **JOBS** start as IN_QUEUE
|
|
44
|
+
- **MUST** update status through lifecycle
|
|
45
|
+
- **SHOULD** set result or error on completion
|
|
46
|
+
- **MUST** handle all status transitions
|
|
47
|
+
- **SHOULD** clean up completed jobs
|
|
48
|
+
|
|
49
|
+
### Error Handling Rules
|
|
50
|
+
- **MUST** set job error on failure
|
|
51
|
+
- **SHOULD** propagate errors to callers
|
|
52
|
+
- **MUST** handle timeout scenarios
|
|
53
|
+
- **SHOULD** log job failures
|
|
54
|
+
- **MUST NOT** leave jobs in invalid state
|
|
55
|
+
|
|
56
|
+
### Polling Rules
|
|
57
|
+
- **SHOULD** poll with appropriate intervals
|
|
58
|
+
- **MUST** implement timeout for polling
|
|
59
|
+
- **SHOULD** handle polling errors
|
|
60
|
+
- **MUST** stop polling on completion
|
|
61
|
+
- **SHOULD NOT** poll too frequently
|
|
62
|
+
|
|
63
|
+
## 🤖 AI Agent Guidelines
|
|
64
|
+
|
|
65
|
+
### When Submitting Jobs
|
|
66
|
+
1. **CALL** submitJob() with model and input
|
|
67
|
+
2. **SAVE** returned job ID
|
|
68
|
+
3. **TRACK** job status
|
|
69
|
+
4. **HANDLE** completion/error
|
|
70
|
+
5. **RETRIEVE** result when ready
|
|
71
|
+
|
|
72
|
+
### When Polling Jobs
|
|
73
|
+
1. **IMPLEMENT** polling loop with timeout
|
|
74
|
+
2. **CHECK** job status each iteration
|
|
75
|
+
3. **WAIT** between polls (exponential backoff)
|
|
76
|
+
4. **RETURN** result on completion
|
|
77
|
+
5. **THROW** on timeout or failure
|
|
78
|
+
|
|
79
|
+
### When Managing Job Lifecycle
|
|
80
|
+
1. **UPDATE** status appropriately
|
|
81
|
+
2. **SET** result on success
|
|
82
|
+
3. **SET** error on failure
|
|
83
|
+
4. **VERIFY** state transitions
|
|
84
|
+
5. **CLEAN UP** old jobs
|
|
85
|
+
|
|
86
|
+
### Code Style Rules
|
|
87
|
+
- **USE** descriptive job inputs
|
|
88
|
+
- **HANDLE** all job status cases
|
|
89
|
+
- **IMPLEMENT** polling with timeout
|
|
90
|
+
- **LOG** job state changes
|
|
91
|
+
- **VALIDATE** job IDs
|
|
92
|
+
|
|
93
|
+
## 📦 Available Class
|
|
94
|
+
|
|
95
|
+
### JobManager
|
|
96
|
+
|
|
97
|
+
**Refer to**: [`JobManager.ts`](./JobManager.ts)
|
|
98
|
+
|
|
99
|
+
**Methods:**
|
|
100
|
+
- `submitJob(model, input)` - Submit new job
|
|
101
|
+
- `getJobStatus(requestId)` - Get job status
|
|
102
|
+
- `getJobResult(requestId)` - Get job result
|
|
103
|
+
- `updateJobStatus(requestId, status)` - Update job status
|
|
104
|
+
- `setJobResult(requestId, result)` - Set job result
|
|
105
|
+
- `setJobError(requestId, error)` - Set job error
|
|
106
|
+
- `getJob(requestId)` - Get job details
|
|
107
|
+
- `clear()` - Clear all jobs
|
|
108
|
+
|
|
109
|
+
## 🔗 Related Modules
|
|
110
|
+
|
|
111
|
+
- **Video Generation Service**: [`../services/VIDEO_GENERATION_SERVICE.md`](../services/VIDEO_GENERATION_SERVICE.md)
|
|
112
|
+
- **Job Processor**: [`../services/JOB_PROCESSOR_SERVICE.md`](../services/JOB_PROCESSOR_SERVICE.md)
|
|
113
|
+
- **Infrastructure README**: [`../infrastructure/README.md`](../infrastructure/README.md)
|
|
114
|
+
|
|
115
|
+
## 📋 Job Status Types
|
|
116
|
+
|
|
117
|
+
### IN_QUEUE
|
|
118
|
+
Job is queued, waiting to start.
|
|
119
|
+
|
|
120
|
+
### PROCESSING
|
|
121
|
+
Job is currently being processed.
|
|
122
|
+
|
|
123
|
+
### COMPLETED
|
|
124
|
+
Job finished successfully with result.
|
|
125
|
+
|
|
126
|
+
### FAILED
|
|
127
|
+
Job failed with error.
|
|
128
|
+
|
|
129
|
+
### CANCELLED
|
|
130
|
+
Job was cancelled before completion.
|
|
131
|
+
|
|
132
|
+
## 🎓 Usage Patterns
|
|
133
|
+
|
|
134
|
+
### Job Submission
|
|
135
|
+
1. Create JobManager instance
|
|
136
|
+
2. Call submitJob() with model and input
|
|
137
|
+
3. Store returned job ID
|
|
138
|
+
4. Monitor job status
|
|
139
|
+
5. Retrieve result when complete
|
|
140
|
+
|
|
141
|
+
### Status Polling
|
|
142
|
+
1. Submit job and get ID
|
|
143
|
+
2. Poll job status periodically
|
|
144
|
+
3. Check for COMPLETED or FAILED
|
|
145
|
+
4. Implement timeout
|
|
146
|
+
5. Return result or throw error
|
|
147
|
+
|
|
148
|
+
### Job Lifecycle Management
|
|
149
|
+
1. Submit job to manager
|
|
150
|
+
2. Update status to PROCESSING
|
|
151
|
+
3. Perform operation
|
|
152
|
+
4. Set result or error
|
|
153
|
+
5. Handle completion
|
|
154
|
+
|
|
155
|
+
## 🚨 Common Pitfalls
|
|
156
|
+
|
|
157
|
+
### Don't
|
|
158
|
+
- Lose job ID after submission
|
|
159
|
+
- Call getJobResult() without checking status
|
|
160
|
+
- Poll too frequently
|
|
161
|
+
- Forget to implement timeout
|
|
162
|
+
- Leave completed jobs in queue
|
|
163
|
+
|
|
164
|
+
### Do
|
|
165
|
+
- Always save job ID
|
|
166
|
+
- Check status before getting result
|
|
167
|
+
- Use exponential backoff for polling
|
|
168
|
+
- Implement timeout for polling
|
|
169
|
+
- Clean up completed jobs
|
|
170
|
+
|
|
171
|
+
---
|
|
172
|
+
|
|
173
|
+
**Last Updated**: 2025-01-08
|
|
174
|
+
**See Also**: [AI_GUIDELINES.md](../../../../AI_GUIDELINES.md)
|
|
@@ -0,0 +1,194 @@
|
|
|
1
|
+
# Job Manager
|
|
2
|
+
|
|
3
|
+
Async job submission, tracking, and status management service. Manages long-running operations with polling capability.
|
|
4
|
+
|
|
5
|
+
## 📍 Import Path
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
import {
|
|
9
|
+
JobManager,
|
|
10
|
+
AIJobStatusType
|
|
11
|
+
} from '@umituz/react-native-ai-gemini-provider';
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
## 🎯 Purpose
|
|
15
|
+
|
|
16
|
+
Use job manager to handle async operations that take time to complete. Provides job lifecycle management, status tracking, and result retrieval.
|
|
17
|
+
|
|
18
|
+
**When to use:**
|
|
19
|
+
- Submit long-running AI operations
|
|
20
|
+
- Track job status over time
|
|
21
|
+
- Implement polling for completion
|
|
22
|
+
- Manage async job lifecycles
|
|
23
|
+
- Handle batch processing
|
|
24
|
+
- Monitor job progress
|
|
25
|
+
- Retrieve results when ready
|
|
26
|
+
|
|
27
|
+
## 📌 Strategy
|
|
28
|
+
|
|
29
|
+
Job manager abstracts async operation complexity. This system:
|
|
30
|
+
- Generates unique job IDs
|
|
31
|
+
- Tracks job status through lifecycle
|
|
32
|
+
- Stores results for retrieval
|
|
33
|
+
- Handles errors gracefully
|
|
34
|
+
- Supports status polling
|
|
35
|
+
- Manages job completion
|
|
36
|
+
|
|
37
|
+
**Key Decision**: Use job manager for video generation and other long-running operations. Poll for status instead of blocking.
|
|
38
|
+
|
|
39
|
+
## ⚠️ Rules
|
|
40
|
+
|
|
41
|
+
### Usage Rules
|
|
42
|
+
- **MUST** save job ID after submission
|
|
43
|
+
- **SHOULD** check job status before getting result
|
|
44
|
+
- **MUST** handle job completion and failure
|
|
45
|
+
- **SHOULD** implement polling for long operations
|
|
46
|
+
- **MUST NOT** lose job IDs
|
|
47
|
+
|
|
48
|
+
### Job Lifecycle Rules
|
|
49
|
+
- **JOBS** start as IN_QUEUE
|
|
50
|
+
- **MUST** update status through lifecycle
|
|
51
|
+
- **SHOULD** set result or error on completion
|
|
52
|
+
- **MUST** handle all status transitions
|
|
53
|
+
- **SHOULD** clean up completed jobs
|
|
54
|
+
|
|
55
|
+
### Error Handling Rules
|
|
56
|
+
- **MUST** set job error on failure
|
|
57
|
+
- **SHOULD** propagate errors to callers
|
|
58
|
+
- **MUST** handle timeout scenarios
|
|
59
|
+
- **SHOULD** log job failures
|
|
60
|
+
- **MUST NOT** leave jobs in invalid state
|
|
61
|
+
|
|
62
|
+
### Polling Rules
|
|
63
|
+
- **SHOULD** poll with appropriate intervals
|
|
64
|
+
- **MUST** implement timeout for polling
|
|
65
|
+
- **SHOULD** handle polling errors
|
|
66
|
+
- **MUST** stop polling on completion
|
|
67
|
+
- **SHOULD NOT** poll too frequently
|
|
68
|
+
|
|
69
|
+
## 🤖 AI Agent Guidelines
|
|
70
|
+
|
|
71
|
+
### When Submitting Jobs
|
|
72
|
+
1. **CALL** submitJob() with model and input
|
|
73
|
+
2. **SAVE** returned job ID
|
|
74
|
+
3. **TRACK** job status
|
|
75
|
+
4. **HANDLE** completion/error
|
|
76
|
+
5. **RETRIEVE** result when ready
|
|
77
|
+
|
|
78
|
+
### When Polling Jobs
|
|
79
|
+
1. **IMPLEMENT** polling loop with timeout
|
|
80
|
+
2. **CHECK** job status each iteration
|
|
81
|
+
3. **WAIT** between polls (exponential backoff)
|
|
82
|
+
4. **RETURN** result on completion
|
|
83
|
+
5. **THROW** on timeout or failure
|
|
84
|
+
|
|
85
|
+
### When Managing Job Lifecycle
|
|
86
|
+
1. **UPDATE** status appropriately
|
|
87
|
+
2. **SET** result on success
|
|
88
|
+
3. **SET** error on failure
|
|
89
|
+
4. **VERIFY** state transitions
|
|
90
|
+
5. **CLEAN UP** old jobs
|
|
91
|
+
|
|
92
|
+
### Code Style Rules
|
|
93
|
+
- **USE** descriptive job inputs
|
|
94
|
+
- **HANDLE** all job status cases
|
|
95
|
+
- **IMPLEMENT** polling with timeout
|
|
96
|
+
- **LOG** job state changes
|
|
97
|
+
- **VALIDATE** job IDs
|
|
98
|
+
|
|
99
|
+
## 📦 Available Classes
|
|
100
|
+
|
|
101
|
+
### JobManager
|
|
102
|
+
|
|
103
|
+
**Refer to**: [`JobManager.ts`](./JobManager.ts)
|
|
104
|
+
|
|
105
|
+
**Methods:**
|
|
106
|
+
- `submitJob(model, input)` - Submit new job
|
|
107
|
+
- `getJobStatus(requestId)` - Get job status
|
|
108
|
+
- `getJobResult(requestId)` - Get job result
|
|
109
|
+
- `updateJobStatus(requestId, status)` - Update job status
|
|
110
|
+
- `setJobResult(requestId, result)` - Set job result
|
|
111
|
+
- `setJobError(requestId, error)` - Set job error
|
|
112
|
+
- `getJob(requestId)` - Get job details
|
|
113
|
+
- `clear()` - Clear all jobs
|
|
114
|
+
|
|
115
|
+
## 🔗 Related Modules
|
|
116
|
+
|
|
117
|
+
- **Video Generation Service**: [`../services/VIDEO_GENERATION_SERVICE.md`](../services/VIDEO_GENERATION_SERVICE.md)
|
|
118
|
+
- **Services README**: [`../services/README.md`](../services/README.md)
|
|
119
|
+
- **Infrastructure README**: [`../infrastructure/README.md`](../infrastructure/README.md)
|
|
120
|
+
|
|
121
|
+
## 📋 Job Status Types
|
|
122
|
+
|
|
123
|
+
### IN_QUEUE
|
|
124
|
+
Job is queued, waiting to start.
|
|
125
|
+
|
|
126
|
+
### PROCESSING
|
|
127
|
+
Job is currently being processed.
|
|
128
|
+
|
|
129
|
+
### COMPLETED
|
|
130
|
+
Job finished successfully with result.
|
|
131
|
+
|
|
132
|
+
### FAILED
|
|
133
|
+
Job failed with error.
|
|
134
|
+
|
|
135
|
+
### CANCELLED
|
|
136
|
+
Job was cancelled before completion.
|
|
137
|
+
|
|
138
|
+
## 🎓 Usage Patterns
|
|
139
|
+
|
|
140
|
+
### Basic Job Submission
|
|
141
|
+
1. Create JobManager instance
|
|
142
|
+
2. Call submitJob() with model and input
|
|
143
|
+
3. Store returned job ID
|
|
144
|
+
4. Monitor job status
|
|
145
|
+
5. Retrieve result when complete
|
|
146
|
+
|
|
147
|
+
### Status Polling
|
|
148
|
+
1. Submit job and get ID
|
|
149
|
+
2. Poll job status periodically
|
|
150
|
+
3. Check for COMPLETED or FAILED
|
|
151
|
+
4. Implement timeout
|
|
152
|
+
5. Return result or throw error
|
|
153
|
+
|
|
154
|
+
### Batch Processing
|
|
155
|
+
1. Submit multiple jobs
|
|
156
|
+
2. Store all job IDs
|
|
157
|
+
3. Poll all jobs in parallel
|
|
158
|
+
4. Collect all results
|
|
159
|
+
5. Return batch results
|
|
160
|
+
|
|
161
|
+
### Job Lifecycle Management
|
|
162
|
+
1. Submit job to manager
|
|
163
|
+
2. Update status to PROCESSING
|
|
164
|
+
3. Perform operation
|
|
165
|
+
4. Set result or error
|
|
166
|
+
5. Handle completion
|
|
167
|
+
|
|
168
|
+
### Error Recovery
|
|
169
|
+
1. Submit job with retry logic
|
|
170
|
+
2. Monitor job status
|
|
171
|
+
3. On failure, check error type
|
|
172
|
+
4. Retry if appropriate
|
|
173
|
+
5. Handle permanent failures
|
|
174
|
+
|
|
175
|
+
## 🚨 Common Pitfalls
|
|
176
|
+
|
|
177
|
+
### Don't
|
|
178
|
+
- Lose job ID after submission
|
|
179
|
+
- Call getJobResult() without checking status
|
|
180
|
+
- Poll too frequently
|
|
181
|
+
- Forget to implement timeout
|
|
182
|
+
- Leave completed jobs in queue
|
|
183
|
+
|
|
184
|
+
### Do
|
|
185
|
+
- Always save job ID
|
|
186
|
+
- Check status before getting result
|
|
187
|
+
- Use exponential backoff for polling
|
|
188
|
+
- Implement timeout for polling
|
|
189
|
+
- Clean up completed jobs
|
|
190
|
+
|
|
191
|
+
---
|
|
192
|
+
|
|
193
|
+
**Last Updated**: 2025-01-08
|
|
194
|
+
**See Also**: [AI_GUIDELINES.md](../../../../AI_GUIDELINES.md)
|