Update autopilot state and dependencies table for architecture shift

- Changed the current step from "Refactor" to "Implement" in the autopilot state, indicating a transition to the next phase of development.
- Updated the dependencies table to reflect the completion of 11 tasks and the addition of 4 new tasks related to the distributed architecture.
- Removed outdated task documentation for AZ-173, AZ-174, AZ-175, and AZ-176 as they are now obsolete following the architectural changes.
- Enhanced the execution order for new tasks, organizing them into batches based on dependencies.

These updates aim to align the project documentation with the current development phase and improve clarity on task management moving forward.
This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-03-31 06:08:44 +03:00
parent 8ce40a9385
commit 6547c5903a
6 changed files with 48 additions and 102 deletions
@@ -0,0 +1,73 @@
# Media Table Integration
**Task**: AZ-175_media_table_integration
**Name**: Integrate Media table: create record on upload, store file, track status
**Description**: When a file is uploaded to the detections API, create a Media record in the DB, store the file at the proper path, and update MediaStatus throughout processing.
**Complexity**: 2 points
**Dependencies**: Annotations service needs Media CRUD endpoints
**Component**: Media Management
**Jira**: AZ-175
**Parent**: AZ-172
## Problem
Currently, uploaded files are written to temp files, processed, and deleted. No `Media` record is created in the database. File persistence and status tracking are missing.
## Current State
- `/detect`: writes upload to `tempfile.NamedTemporaryFile`, processes, deletes via `os.unlink`
- `/detect/{media_id}`: accepts a media_id parameter but doesn't create or manage Media records
- No XxHash64 ID generation in the detections module
- No file storage to persistent paths
## Target State
### On Upload
1. Receive file bytes from HTTP upload
2. Compute XxHash64 of file content using the sampling algorithm
3. Determine MediaType from file extension (Video or Image)
4. Store file at proper path (from DirectorySettings: VideosDir or ImagesDir)
5. Create Media record via annotations service: `POST /api/media`
- Id: XxHash64 hex string
- Name: original filename
- Path: storage path
- MediaType: Video|Image
- MediaStatus: New (1)
- UserId: from JWT
### During Processing
6. Update MediaStatus to AIProcessing (2) via `PUT /api/media/{id}/status`
7. Run detection (stream-based per AZ-173)
8. Update MediaStatus to AIProcessed (3) on success, or Error (6) on failure
## XxHash64 Sampling Algorithm
```
For files >= 3072 bytes:
Input = file_size_as_8_bytes + first_1024_bytes + middle_1024_bytes + last_1024_bytes
Output = XxHash64(input) as hex string
For files < 3072 bytes:
Input = file_size_as_8_bytes + entire_file_content
Output = XxHash64(input) as hex string
```
Virtual hashes (in-memory only) prefixed with "V".
## Acceptance Criteria
- [ ] XxHash64 ID computed correctly using the sampling algorithm
- [ ] Media record created in DB on upload with correct fields
- [ ] File stored at proper persistent path (not temp)
- [ ] MediaStatus transitions: New → AIProcessing → AIProcessed (or Error)
- [ ] UserId correctly extracted from JWT and associated with Media record
## File Changes
| File | Action | Description |
|------|--------|-------------|
| `src/main.py` | Modified | Upload handling, Media API calls, status updates |
| `src/media_hash.py` | New | XxHash64 sampling hash utility |
| `requirements.txt` | Modified | Add `xxhash` library if not present |