jss install reports '0/N installed' when the push actually extracted and the app serves #560
Description
Problem
With --body-limit 200MB (flag or JSS_BODY_LIMIT env — both behave identically), installing the larger apps produces a contradiction (jss 0.0.207, fresh --git --idp --single-user pod):
- jss install prints push errors and "0/2 installed"
- but both apps are on disk with extracted working trees and serve HTTP 200 at /public/apps/<name>/
Server log for the same run shows a mix of 200s and 413s on POST .../git-receive-pack (chat: 2×200 + 2×413), and git stderr ends with Everything up-to-date — i.e. at least one of the dual pushes (HEAD:main + HEAD:gh-pages) succeeded and extracted, while the failure of the other counted the whole app as failed.
Expected
If the working tree extracted (the thing the user cares about), the app should count as installed — or at minimum the summary should say "installed with warnings", not imply nothing happened. Success detection should probably check the extracted state (or at least treat one successful push of the dual pair as success, which is already the semantics the dual-push design intends).
Companion issues: default body-limit vs default bundle; residual 413s at a 200MB limit.
Activity
melvincarvalho commented on Jun 11, 2026
Correction: the premise of this issue is wrong — I retract the "app actually installed and serves" claim. Deeper investigation (see #561) showed:
So jss install's failure report was accurate. The real UX bug here is the leftover state:
Suggested fix: either clean up the auto-inited repo when the receive-pack that triggered it never lands (or fails), or make jss install's "already in use" check distinguish an empty auto-inited repo (no refs, no working tree) from a real app — an empty one should be safe to push into rather than skipped.
Retitling suggestion: "Failed first push leaves an empty auto-inited repo; retries report 'path already in use'".