Changed from apiCall('create_identity_from_face') to updateTraceProfileGroup(name).
This correctly creates a new face group by renaming trace_profiles.name
instead of trying to register a global identity.
Changed from apiCall('merge_trace', ...) to updateTraceProfileGroup(name=targetGroup.name).
This just changes the trace profile name to join the target group,
without actually merging trace data together.
Changed from apiCall('delete_trace', ...) to updateTraceProfileGroup(name='Unassigned').
This preserves all trace data and just removes the group assignment.
Traces move back to Pending Faces instead of being deleted.
- loadTraceThumb now uses /api/v1/trace-thumb/{uuid}/{tid} (~8ms)
- Face group imgs use direct trace-thumb URL with fallback
- Merge dialogs also use direct trace-thumb with fallback
- MAX_CONCURRENT increased to 32
Fallback chain:
1. c.rep_trace.file_uuid/trace_id (full trace data)
2. selectedFileUuid/representative_trace (group data only)
3. SVG silhouette
- Add v-observe directive to face groups for lazy thumbnail loading
- Increase MAX_CONCURRENT from 16 to 32 for faster parallel loading
- Apply lazy loading to merge dialogs and candidate groups
- Only load thumbnails when cards become visible (IntersectionObserver)
Improves initial load time for Charade (153 groups, 2451 traces) from
~76s to <5s for visible groups.
- Add UNREGISTER_TIMEOUT=200000 (200s) for large file unregister
- Add timeout field to buildHttpRequest return type
- httpCall now uses per-request timeout override
- unregister_file now uses asyncMode: true for better UX
- Show "Removing in background..." toast for async mode
Fixes timeout error when unregistering large files (83K faces, 20K nodes).
- Add 'Face Group' mode to search modes
- Use search_identities API temporarily
- Update summary: 'Identity' → 'FS'
- Will replace with Core Team's search_tkg_node_face_trace_profile API
- Rename computed property to match current API semantics
- face_groups are definitive, not pending
- Add detailed console.log for debugging empty groups issue
- Explicitly define data source for Move Faces Modal
- Use clusterAsPending directly
- Add console.log for debugging
Purpose: Diagnose why only one group shows in Move Faces Modal
Problem:
- Some groups may not have name field
- Display would show blank or undefined
Solution:
- Add fallback: c.name || 'Unnamed Group'
- Add fallback: c.trace_count || 0
- Ensures always shows meaningful text
Impact:
- Move Faces Modal now always shows group names
- No blank entries even with incomplete data
Replace merge_trace implementation with merge_groups API
Changes:
1. src/api/index.ts:
- Add merge_groups API definition
- POST /api/v1/file/:file_uuid/groups/merge
- Parameters: file_uuid, source_groups[], target_group_name
2. src/views/PeopleView.vue:
- Rewrite executeMerge() function
- Use group names instead of trace IDs
- Single API call for all groups
- Remove trace-level loop
3. src/views/PeopleView.vue:
- Delete updateClusterAfterMerge() function
- No longer needed with new API
Benefits:
- ✅ Atomic operation (single API call)
- ✅ Correct merge behavior (groups, not traces)
- ✅ Better performance (1 call vs N calls)
- ✅ Data consistency guaranteed
API behavior:
- Merge N groups into 1 target group
- All traces from source groups merged to target
- Source groups deleted after merge
- Returns traces_merged count
Core API: Implemented by Core Team (2026-07-25)
Status: Ready for testing
Display format with # separator:
- Frame: F#{number} (e.g., F#333)
- Face Trace: FS#{number} (e.g., FS#233)
Changes:
- Line 105: Frame range display (F#2219–F#2225)
- Line 143: Face Detail Modal (file_uuid:FS#233)
- Line 262: Cluster strip fallback (FS#233)
- Line 264: Cluster strip label (FS#233)
Benefits:
- # separator makes ID clearer
- Consistent format across all displays
- Visual distinction between type and number
Critical bug fix:
- updateClusterAfterMerge() was called after EACH trace merge
- This caused source group to be deleted after first trace
- Remaining traces had no group to merge into
Problem flow:
1. Merge trace #1 from Group B → Group A
2. updateClusterAfterMerge(B, A) deletes Group B
3. Try to merge trace #2 from Group B → Group B is gone!
4. Result: All source groups deleted after first trace
Solution:
- Remove updateClusterAfterMerge() from loop
- Let all traces merge successfully
- Reload cluster data at the end (Line 1813)
- Core API handles the merge, we just refresh UI
Impact:
- Merge now works correctly for all traces in a group
- No premature deletion of source groups
- UI refreshes after all operations complete
Problem:
- After merge, source groups become empty
- Empty groups stay in UI as garbage data
- User sees empty groups with 0 faces
Solution:
- updateClusterAfterMerge() now removes source groups after merge
- Added removal from clusterAsPending computed property
- Ensures clean UI after merge operation
Behavior:
- Source group is deleted after all members merged to target
- Target group receives all members
- No empty groups left in UI
Related: merge functionality debug logging added in previous commit
Add debug logs to diagnose merge not working issue:
1. batchMergeGroups():
- Log selected groupIds
- Log mergeCandidateGroups count
2. executeMerge():
- Log targetGroupId and targetGroup
- Log targetTraceId type and value
- Log targetTrace data
- Log sourceGroups count
- Log totalTraces and validTraces
- Log each merge_trace API call params
- Log success/fail counts
Purpose: Identify why merge fails when move works
Next: Check browser console for specific errors
Problem:
- 'F13' display text confused with Frame numbers
- Users cannot distinguish between Trace ID and Frame Number
Solution:
- Change display format from 'F{trace_id}' to 'Face{trace_id}'
- Example: F13 → Face13, F142 → Face142
Changes:
- src/views/PeopleView.vue:264 - Cluster Detail Modal label
Benefits:
- Clear semantic meaning (Face vs Frame)
- No ambiguity for users
- Display layer only, data layer unchanged (still trace_id)
Problem:
- syncFileStatus() doesn't load pipeline progress data
- Files stuck in 'processing' without percentage display
- pollPipelineProgress() not started when pipeline data missing
Solution:
1. Add loadPipelineStats() call in syncFileStatus() for processing files
2. Start pollPipelineProgress() even when pipeline data is missing
3. Ensure progress bar always has data to display
Impact:
- Progress bar now shows percentage during deep scan
- Files no longer stuck in 'processing' state indefinitely
- Better handling of edge cases when API data is missing
Related: Core team needs to verify get_pipeline_stats API accuracy
Problem:
- Status badge showed 'Scanning'
- Progress bar showed 'Processing...'
- Two different texts displayed simultaneously
Solution:
- Change progress bar text to 'Scanning...'
- Now both badge and progress bar use consistent terminology
