Bridge installer: make the bundled jar a real fallback (#103 follow-up) - #111
Merged
Conversation
installBridge picked one source and committed to it, so the jar shipped with the app only covered GitHub being unreachable. The commoner failure is the API answering while the asset download does not — a dropped connection, or a proxy that allows api.github.com but not objects.githubusercontent.com — and there the install refused with a perfectly good jar on disk. That is what shipping the jar is for. installPlan() returns an ordered list and the installer walks it; a bad-asset refusal falls through the same way, since "the release is wrong" is exactly when the local copy is worth having. bridgeStatus reads the first step of the same plan rather than repeating the ordering, so the version the warning names is the version the button delivers. installedJars matched only enabled jars, so a disabled bridge jar was invisible: the status offered to install a version already sitting there, and the post-install cleanup skipped it, so a server accumulated a disabled bridge per version its operator ever turned off. Disabled jars are now found and cleaned up; installedBridgeVersion still counts only enabled ones, because Bukkit does not load one.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Self-review
1. The bundled jar was a fallback for one failure, and not the likely one
installBridgepicked a source and committed to it: newest wins, and if thatwas GitHub then a failed download refused the install. So the bundled jar
covered exactly one case — GitHub's API being unreachable, which is what makes
latestBridge()return null.The commoner failure is not that. It is the API answering while the asset
download fails: a CDN hiccup, a connection dropped mid-stream, or a corporate
proxy that allows
api.github.combut notobjects.githubusercontent.com.In all of those the old code refused, with a perfectly good jar sitting in
resources/.That is the whole point of shipping the jar, missed by one
else if.installPlan()now returns an ordered list and the installer walks it. Abad-assetrefusal falls through the same way a download failure does, since"the release is wrong" is exactly when the local copy is worth having. An older
bundled jar is still a working bridge, and the result reports which source it
came from, so nothing is claimed that is not true. Downloading a release older
than the bundled one stays excluded — that is work done to arrive somewhere
worse.
bridgeStatusnow reads the first step of the same plan, so the version thewarning names is the version the button delivers; it had its own copy of the
ordering, which is two places to change and one to forget.
Proved failable: reducing the plan to
['github']givesFAIL - a failed download would not fall back to the bundled jar: github.2. A disabled bridge was invisible, so an install left two of them
installedJarsmatchedMSMS-Bridge-1.0.0.jarand therefore never sawMSMS-Bridge-1.0.0.jar.disabled. Two consequences: the status reportedmissingand offered to install 1.0.0 to someone who already had 1.0.0 sittingthere disabled, and the post-install cleanup — which exists so the folder never
holds two bridges — skipped it. A server whose operator had turned the plugin
off once would accumulate a disabled jar per version forever.
Disabled jars are now found and cleaned up, while
installedBridgeVersionstillonly counts enabled ones: Bukkit does not load a
.disabled, so reporting it asinstalled would be a lie in the other direction.
Not fixed
installBridgecannot be exercised end-to-end by the smoke — it needs either anetwork or a writable fixture with a recognised server type, and the gate has
neither. The ordering is asserted as a pure decision and the route is asserted
to ignore a caller-supplied url/version/name; the download itself is not.
Verified
Twelve gates green.