mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-25 09:06:02 +03:00
[GH-ISSUE #783] Bug: Sorting by file size throws "Server Error (500)" #2008
Labels
No labels
expected: maybe someday
expected: next release
expected: release after next
expected: unlikely unless contributed
good first ticket
help wanted
pull-request
scope: all users
scope: windows users
size: easy
size: hard
size: medium
size: medium
status: backlog
status: blocked
status: done
status: idea-phase
status: needs followup
status: wip
status: wontfix
touches: API/CLI/Spec
touches: configuration
touches: data/schema/architecture
touches: dependencies/packaging
touches: docs
touches: js
touches: views/replayers/html/css
why: correctness
why: functionality
why: performance
why: security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ArchiveBox#2008
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @AlexanderRitter02 on GitHub (Jul 6, 2021).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/783
Describe the bug
Trying to sort snapshots by file size results in "Server Error (500)" when clicking on the SIZE header.
Clicking where displayed in the picture:


Results in:
I already tried running
archivebox init, since that was suggested on similar issues, but it did not help.I will happily provide any more information.
Steps to reproduce
I am using the Docker-Compose install on Windows.
docker-compose -up)http://127.0.0.1:8000/admin/core/snapshot/❌ This will lead to the page
http://127.0.0.1:8000/admin/core/snapshot/?o=4.-1which displays a big Server Error (500).Screenshots or log output
ArchiveBox version
@pirate commented on GitHub (Jul 6, 2021):
Sorting by actualy on-disk size is not really possible in the current version, as we don't save the size in the DB so it's not a sortable column. It's lazily computed and cached on each pageload. What I tried to do was sort by number of succesful
ArchiveResults (which is only a weak proxy for archive size), but I didn't test it super thoroughly or spend a lot of time implementing that, so I'm not surprised it's broken.Thanks for reporting.