80 lines
2.6 KiB
Markdown
80 lines
2.6 KiB
Markdown
|
|
NEXT DEBUGGING SESSION
|
||
|
|
======================
|
||
|
|
|
||
|
|
Run these commands in sequence and watch the [add-file] and [search-store] debug logs:
|
||
|
|
|
||
|
|
Step 1: Search and observe table/items mismatch
|
||
|
|
------
|
||
|
|
$ search-store system:limit=5
|
||
|
|
|
||
|
|
Expected output:
|
||
|
|
- Should see your 4 items in the table
|
||
|
|
- Watch for: [search-store] Added X rows to table, Y items to results_list
|
||
|
|
- If X=1 and Y=4: Problem is in table.add_result() or _ensure_storage_columns()
|
||
|
|
- If X=4 and Y=4: Problem is in CLI selection mapping (elsewhere)
|
||
|
|
|
||
|
|
Step 2: Test selection with debugging
|
||
|
|
------
|
||
|
|
$ @2 | add-file -storage test
|
||
|
|
|
||
|
|
Expected output:
|
||
|
|
- [add-file] INPUT result details should show the item you selected
|
||
|
|
- [add-file] RESOLVED source should have hash and store
|
||
|
|
- If either is missing/wrong: result object structure is wrong
|
||
|
|
- If both are correct: problem is in source resolution logic
|
||
|
|
|
||
|
|
Step 3: If selection works
|
||
|
|
------
|
||
|
|
If you successfully select @2 and add-file processes it:
|
||
|
|
- Congratulations! The issue was a one-time glitch
|
||
|
|
- If it fails again, compare debug logs to this run
|
||
|
|
|
||
|
|
Step 4: If selection still fails
|
||
|
|
------
|
||
|
|
Collect these logs:
|
||
|
|
1. Output of: search-store system:limit=5
|
||
|
|
2. Output of: @2 | add-file -storage test
|
||
|
|
3. Run diagnostic command to verify table state:
|
||
|
|
$ search-store system:limit=5 | .pipe
|
||
|
|
(This will show what .pipe sees in the results)
|
||
|
|
|
||
|
|
Step 5: Understanding @N selection format
|
||
|
|
------
|
||
|
|
When you see: [debug] first-stage: sel=[1] rows=1 items=4
|
||
|
|
- sel=[1] means you selected @2 (0-based index: @2 = index 1)
|
||
|
|
- rows=1 means the table object has only 1 row registered
|
||
|
|
- items=4 means there are 4 items in the results_list
|
||
|
|
|
||
|
|
The fix depends on which is wrong:
|
||
|
|
- If rows should be 4: table.add_result() isn't adding rows
|
||
|
|
- If items should be 1: results are being duplicated somehow
|
||
|
|
|
||
|
|
QUICK REFERENCE: DEBUGGING COMMANDS
|
||
|
|
===================================
|
||
|
|
|
||
|
|
Show debug logs:
|
||
|
|
$ debug on
|
||
|
|
$ search-store system:limit=5
|
||
|
|
$ @2 | add-file -storage test
|
||
|
|
|
||
|
|
Check what @2 selection resolves to:
|
||
|
|
$ @2 | get-metadata
|
||
|
|
|
||
|
|
Alternative (bypass @N selection issue):
|
||
|
|
$ search-store system:limit=5 | get-metadata -store home | .pipe
|
||
|
|
|
||
|
|
This avoids the @N selection and directly pipes results through cmdlets.
|
||
|
|
|
||
|
|
EXPECTED BEHAVIOR
|
||
|
|
================
|
||
|
|
|
||
|
|
Correct sequence when selection works:
|
||
|
|
1. search-store finds 4 results
|
||
|
|
2. [search-store] Added 4 rows to table, 4 items to results_list
|
||
|
|
3. @2 selects item at index 1 (second item: "i ve been down")
|
||
|
|
4. [add-file] INPUT result is dict: title=i ve been down, hash=b0780e68a2dc..., store=hydrus
|
||
|
|
5. [add-file] RESOLVED source: path=/tmp/medios-hydrus/..., is_hydrus=True, hash=b0780e68a2dc...
|
||
|
|
6. File is successfully added to "test" storage
|
||
|
|
|
||
|
|
If you see different output, the logs will show exactly where it diverges.
|