264 AnKing Step Deck images fail to sync (403 from S3) despite existing locally — stale exists_on_s3 flags

🐛 Bug
1

Media sync repeatedly tries to re-download ~264 files and fails with 403 AccessDenied from S3 (https://ankihub.s3.amazonaws.com/deck_assets/e77aedfe.../``<file>). This happens on every sync, going back through all my logs to January 2026.

I dug into it locally:

  • All 264 files already exist in my collection.media folder.

  • Their local MD5 doesn’t match file_content_hash in the add-on’s local deck_media table, so the sync keeps queuing them for re-download.

  • The deck_media rows for these files are flagged exists_on_s3 = 1, but fetching the S3 URL directly returns 403/AccessDenied — same behavior as a missing object on that bucket.

  • Rows are stamped modified = 2023-09-29, so they look stale and never got corrected server-side.

This seems to be inconsistent metadata for this deck (files marked as present on S3 that aren’t retrievable), not a problem with my install. Could someone check/re-flag or re-upload those objects for this deck? Happy to share the exact filename list.

6

Hi, we have notified the developers, and you are not the only one facing this error. A developer will get in touch here if they need more information, and we will keep you updated on any news.

1 Like
7

Hi,

Can you share the filename list? I cannot reproduce this with a fresh install - it might be the case of the add-on failing to clear old entries from deleted files.

8

Thanks @abdo.nh — filename list attached (ankihub_264_filenames.txt, plus
ankihub_264_details.csv with per-file metadata).

Short version: I don’t think these are leftovers from deleted files. All 264
are still flagged as referenced by accepted notes.

From my local ankihub.db (deck_media, deck e77aedfe-a636-40e2-8169-2fce2673187e),
cross-checked against collection.media and the add-on logs:

  • 264 distinct files 403 on every sync — the identical set across the last 12
    sync days, and going back through 42 sync days in my logs.
  • All 264 resolve to a deck_media row.
  • All 264 have referenced_on_accepted_note = 1, exists_on_s3 = 1,
    download_enabled = 1.
  • All 264 are stamped modified = 2023-09-29. Every one, no other date.
  • All 264 exist in my collection.media, and for all of them local MD5 !=
    file_content_hash, which is why they keep getting re-queued.

So from the add-on’s point of view these are live, referenced,
supposedly-present-on-S3 files, not orphans. That may also be why a fresh
install doesn’t reproduce it — the bad rows are all from that one
2023-09-29 batch.

One possible lead on the 403 itself: 89 of the 264 are requested with “+”
where the stored filename has a space.

requested : /deck_assets/e77aedfe-…/Aortic+regurgitation+S1+S2.png
deck_media: Aortic regurgitation S1 S2.png

9 of those also use %28/%29 for parentheses, e.g.
Zenker+diverticulum+%281%29.JPG → Zenker diverticulum (1).JPG

In an S3 path, “+” is a literal plus rather than a space, so if the key
really contains spaces that request would miss and return AccessDenied on a
bucket without ListBucket. Might be worth checking whether the request
encoding matches the actual key. The other 175 are plain hash-style names
with no encoding involved, so that alone wouldn’t explain all of them.

Happy to run anything else against my local DB if it helps.