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! |
rtyley
added a commit
to guardian/hmac-headers
that referenced
this issue
Nov 22, 2024
[`gha-scala-library-release-workflow`](https://github.com/guardian/gha-scala-library-release-workflow) provides these benefits: * **better security for release credentials** by isolating release phases into separate GitHub Workflow Jobs * **removes a lot of sbt configuration** (`gha-scala-library-release-workflow` automatically provides sensible defaults) * **automated version compatibility checking**, detecting binary & source incompatibilities, and setting SemVer-compliant version numbers appropriately - meaning that developers no longer have to assign version numbers, and sbt can now reliably detect when dependency eviction could cause runtime errors (see eg guardian/facia-scala-client#301 !) - and so block those problems at build time. The configuration changes for adopting `gha-scala-library-release-workflow` are documented in [configuration.md](https://github.com/guardian/gha-scala-library-release-workflow/blob/main/docs/configuration.md) .
rtyley
added a commit
to guardian/hmac-headers
that referenced
this issue
Nov 23, 2024
[`gha-scala-library-release-workflow`](https://github.com/guardian/gha-scala-library-release-workflow) provides these benefits: * **better security for release credentials** by isolating release phases into separate GitHub Workflow Jobs * **removes a lot of sbt configuration** (`gha-scala-library-release-workflow` automatically provides sensible defaults) * **automated version compatibility checking**, detecting binary & source incompatibilities, and setting SemVer-compliant version numbers appropriately - meaning that developers no longer have to assign version numbers, and sbt can now reliably detect when dependency eviction could cause runtime errors (see eg guardian/facia-scala-client#301 !) - and so block those problems at build time. The configuration changes for adopting `gha-scala-library-release-workflow` are documented in [configuration.md](https://github.com/guardian/gha-scala-library-release-workflow/blob/main/docs/configuration.md) .
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.
flowchart story-packages("App Server") story-packages --"depends on v17.4.0"--> content-api-models-json --"depends on v17.4.0"--> content-api-models-scala story-packages --"depends on"--> fapi-client-play28 --"depends on "--> content-api-client --"depends on v17.5.2"--> content-api-models-scalaWhat 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: