Skip to content

fix(server): increment total_downloads on pack download#12

Merged
Ghost-Frame merged 1 commit into
feat/land-m3from
fix/download-counter
Jun 29, 2026
Merged

fix(server): increment total_downloads on pack download#12
Ghost-Frame merged 1 commit into
feat/land-m3from
fix/download-counter

Conversation

@Ghost-Frame

Copy link
Copy Markdown
Owner

Problem

Every pack on the marketplace reports total_downloads: 0. Root cause: the counter that backs total_downloads is only bumped by CatalogBackend::increment_download_counter, and no route ever called it. The download handler called record_download (which only inserts a pack_downloads row feeding the 7-day Trending window), so the cumulative counter never moved.

Fix

  • download_pack_bytes now calls increment_download_counter alongside record_download, best-effort (warn and continue on error, never fail a delivered download).
  • Documented why the signed /dl/{hash} path can't increment it (only has the content hash; the official client uses the direct /pack route).
  • Added an integration test asserting a successful download bumps the counter (causally coupled to the bug).

Verification

cargo build -p frameshift-server and cargo test -p frameshift-server pass (73 tests incl. the new download_pack_increments_download_counter). Postgres-backed integration tests were not run (require a live DB); the new test uses the mock catalog.

Base is feat/land-m3 because the touched files diverge from main on that branch.

The catalog `total_downloads` counter shown on the marketplace was never
incremented by any route: the download handler only recorded a `pack_downloads`
event (which feeds the 7-day Trending ranking), while the counter that backs
`total_downloads` is bumped exclusively by `increment_download_counter`, which
no handler called. As a result every pack reported 0 total downloads.

Wire `increment_download_counter` into `download_pack_bytes` alongside the
existing `record_download` call, as a best-effort step that warns and continues
on failure so a download the client already received is never failed. Document
why the signed `/dl/{hash}` path cannot increment the counter (it has only the
content hash, not name/version; the official client uses the direct route).

Add an integration test asserting a successful download increments the counter.
@Ghost-Frame
Ghost-Frame merged commit b39816d into feat/land-m3 Jun 29, 2026
5 of 6 checks passed
@Ghost-Frame
Ghost-Frame deleted the fix/download-counter branch June 29, 2026 19:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant