Github Download Zip Truncation BUG / 404

[CollinChaffin]

Not sure if this is a recent change, but recently have hit instances where weird truncation is occurring due to branch names, which in turn causes an erroneous 404 and failure.

Here is one example I just hit, where disabling the userscript results in the branch zip download success:
https://github.com/hoppfrosch/Clipjump/tree/hoppfrosch/feature/class_clipjumpdb

With the Zip userscript disabled, the repo zip ball download is: https://github.com/hoppfrosch/Clipjump/archive/hoppfrosch/feature/class_clipjumpdb.zip

But with the zip userscript enabled, an inspect reveals the link becomes: https://api.github.com/repos/hoppfrosch/Clipjump/zipball/hoppfrosch/fea…

Which oddly results in the redirect and eventual 404 error and the address bar value of: https://codeload.github.com/hoppfrosch/Clipjump/legacy.zip/hoppfrosch/fea%E2%80%A6

Note the weird addition of legacy.zip in the final redirect url - does that make any sense to you?

It's obvious what's happening in the truncation, but without a lot of digging I'm not clear on exactly where in the code it's being thrown off or a root cause, but I'm sure you'll take one look and probably have a good idea. Note I've only seen this occur on longer-named branches other than master.

[Mottie]

Hi @CollinChaffin!

Thanks for reporting this issue. I was grabbing the truncated text. It's been fixed in the latest release.

[CollinChaffin]

Hi @Mottie Rob!

Thanks so much for looking at this so quickly! I just tested it and as cool as the new addition of the latest release at the bottom of the zip dropdown is, I think there is a new bug related to this addition as well as more importantly the main repo ZIP link seems to now no longer work on any repo, and seems to produce this redirect URL (again adding this weird legacy.zip into the base URL) but now also referring to "switching branches or tags"?:

Example Repo:
https://github.com/tablacus/TablacusExplorer

Main repo ZIP link nav bar URL (404) which appears to be common to all repos I've tested so far when attempting to download repo via main ZIP button produces:
https://codeload.github.com/tablacus/TablacusExplorer/legacy.zip/Switch%20branches%20or%20tags

Secondary (new) behavior (bug?) specific to only one scenario

When a repo DOES have any releases tagged (other than source code), the new dropdown Latest Release Files works great and does list the single latest release (of each type) with latest equivalent tag. However, use this repo as an example where the latest release tag leads to a tagged release, but of type archive "source code" zips only, and instead the new Latest Release Files prefetch fails to load the latest tag. I am guessing it is because despite being a tagged release as in the example below, the url type is truly not a release url but an archive one? Is this intended behavior or ?

Example repo:
https://github.com/deanoemcke/thegreatsuspender

Thanks again for these awesome features! Just having the zip ball including the commit (the part not working) has become an invaluable time saver!

[Mottie]

Hi!

Hmm, yeah. I guess I need to find a better source to get the current branch.

As for the lastest release files dropdown, that should be fixed in a release I just made less than an hour ago.

[Mottie]

Ok, try it now.

[CollinChaffin]

Hey Rob @Mottie!

Looks awesome now! The only thing to possibly just note in release notes etc. or if anyone asks, is that the addition of the latest official tagged releases will not reflect a "source code" release. This makes perfect sense to me; however what does NOT make sense to me is why GH ever allows categorizing nothing more than a source zipball which in essence is identical to the front page download to increment the usual releases GH repo tab. I mention it because when there are no true "releases", this userscript places the No release files found text, whereas in this unique scenario, it does look like it's attempting to retrieve and then just returns blank results. No biggie - just a 3rd possible return value to be aware of.

As an example, this repo https://github.com/deanoemcke/thegreatsuspender shows a count of 15 tagged releases on the repo tab, yet all those releases are simply source and in turn due to that category the URL even changes, and this userscript in turn ignores them but does not categorize it with the No release files found. Personally, I think the script is handling it more correctly than the native site code is. :)

Thanks again for this!

-C