Runtime compatibility errors (eg NoSuchMethodError)
#301
Comments
rtyley
added a commit
to guardian/content-api-scala-client
that referenced
this issue
Jan 25, 2024
…s-scala Now that guardian/content-api-models#232 has been merged and https://github.com/guardian/content-api-models/releases/tag/v18.0.1 has been released, the content-api-models models now declare themselves to adhere to 'early-semver' - and even more than that, thanks to sbt-version-policy, they actually _do_ adhere to it! This should mean that it is **no longer possible** for a single project that depends on content-api-scala-client & content-api-models to have _incompatible_ versions of those artifacts - sbt will reject the incompatibility **at compile time**, where it can be fixed by just ensuring that all libraries (eg including facia-scala-client) have all been compiled against the same versions: https://www.scala-lang.org/blog/2021/02/16/preventing-version-conflicts-with-versionscheme.html This should prevent horrible runtime errors like guardian/facia-scala-client#301 which occurred with the rollout of the innocent-looking changes in https://github.com/guardian/facia-scala-client/releases/tag/v4.0.6 .
|
Very happy indeed we can now close it! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
fapi-clientlibraries depend on several Guardian libraries that can easily become incompatible with each other:content-api-clientcontent-api-modelsWhen app servers use
fapi-clientand (possibly independently)content-api-client/content-api-models, the ultimate versions of those libraries used can be binary-incompatible. This will lead to fatal runtime errors at unpredictable times.How unpredictable are these runtime errors?
Upgrading to
fapi-clientv4.0.6 led to fatal errors on in production on fronts.gutools.co.uk - not immediately on startup, but when a user made a search query that happened to return podcast results. This is obviously very hard to anticipate and test for!The upgrade that caused this issue was actually content-api-models v17.5.1 → v17.5.2 - a very innocent-looking change.
What can we do?
See PREVENTING VERSION CONFLICTS WITH VERSIONSCHEME - in summary, you need all 3 of these things:
ThisBuild / versionScheme := Some("early-semver")configuration to libraries we want to provide protection for (eg facia-scala-client, content-api-scala-client, content-api-models, etc)major.minor.patchversion number updates, that respect Scala's Recommended Versioning Scheme, which is an extended set of rules adding on to plain semver.This last part is being addressed with https://github.com/guardian/gha-scala-library-release-workflow and
sbt-version-policy.The text was updated successfully, but these errors were encountered: