PROD Builds starting to fail since FailedToDeserializePathParams error

[gilgabo]

Bug Report

Version

v0.8.1

Platform

Unix

Crates

axum

Description

#20 176.0 error[E0015]: cannot call non-const fn FailedToDeserializePathParams::status in constant functions
#20 176.0 --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/axum-0.8.1/src/extract/rejection.rs:151:1
#20 176.0 |
#20 176.0 151 | / composite_rejection! {
#20 176.0 152 | | /// Rejection used for Path.
#20 176.0 153 | | ///
#20 176.0 154 | | /// Contains one variant for each way the Path extractor
#20 176.0 ... |
#20 176.0 159 | | }
#20 176.0 160 | | }
#20 176.0 | |^
#20 176.0 |
#20 176.0 = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants
#20 176.0 = note: this error originates in the macro composite_rejection (in Nightly builds, run with -Z macro-backtrace for more info)
#20 176.0
#20 176.0 error[E0015]: cannot call non-const fn InvalidUtf8InPathParam::status in constant functions
#20 176.0 --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/axum-0.8.1/src/extract/rejection.rs:162:1
#20 176.0 |
#20 176.0 162 | / composite_rejection! {
#20 176.0 163 | | /// Rejection used for RawPathParams.
#20 176.0 164 | | ///
#20 176.0 165 | | /// Contains one variant for each way the RawPathParams extractor
#20 176.0 ... |
#20 176.0 170 | | }
#20 176.0 171 | | }
#20 176.0 | |^
#20 176.0 |
#20 176.0 = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants
#20 176.0 = note: this error originates in the macro composite_rejection (in Nightly builds, run with -Z macro-backtrace for more info)
#20 176.0

[Turbo87]

hmm, I guess the latest change in axum-core was technically a breaking change and is incompatible with axum 0.8.0 and 0.8.1. if you upgrade axum to 0.8.2 the issue should be resolved though.

[jplatte]

Damn, what an awkward failure mode. I'd say to prevent this sort of thing from happening again, we should bite the bullet and copy-paste the macros to every individual crate. Then upgrading only axum-core w/o axum would have only added const there, which would not have been an error.

[Turbo87]

I'm not a fan of the duplication that that would bring. I'd say we need to be more careful with potential breaking changes in axum-core instead :)

[gilgabo]

Our company's PROD builds are still failing for this breaking change. Any workaround? Are you planning to solve at axum-core crate?

[Turbo87]

if you upgrade axum to 0.8.2 the issue should be resolved though

see above...

[gilgabo]

Yes, but upgrade the version means create hotfix release for all our projects 😟

[Turbo87]

I don't understand why you need to hotfix something.

• if your project is a library then you are probably using e.g. axum = "0.8.0" syntax, which already allows 0.8.2 to be installed too.
• if you project is an application then I recommend pinning all of your dependencies (e.g. axum = "=0.8.0") and putting the lockfile into git.

[gilgabo]

Yes, that's makes sense, but in a Productive environment you need to do a lot stuff just to change the version is not just modify the Cargo file (like when you are working in a POC or personal / small project).

For us it is a great effort, time and implies having downtimes of our products due to a breaking change that we are not introducing by us (it is a side effect of a change by Axum)

[jplatte]

If upgrading is such a big deal, then how did you get into this situation in the first place? How did you upgrade axum-core without upgrading axum, and not notice that your app now failed to compile?

[gilgabo]

Pipelines were working properly in the afternoon without any change, everything was in Green state. At night we have triggered our validation pipelines again without introduce any change or update, just execute a build (which implies compile, deployment and other tasks) and they have started to fail with the error stack attached above.

For us, since we are not pushed any code or configuration change, It looks like a introduced side effect / change from axum since we are not updating any file in our projects

[oscarAppd2c]

I believe that introducing breaking changes, can have significant implications for production environments. While upgrading dependencies might seem straightforward in smaller projects or development environments, it often requires a more extensive process in larger, production-grade systems.
It might be worth considering ways to minimize such impacts in the future, whether through stricter versioning policies or improved communication of potential risks when introducing changes

[jplatte]

Your pipeline must do some really weird stuff then, if it pulls in a new version of axum-core automatically, without updating other dependencies like axum.

I have yanked the new releases for now. If that doesn't fix your issue, there is nothing I can do for you. I'll look to release axum-core 0.5.2 / axum 0.8.3 / axum-extra 0.11.1 in the coming days, hopefully without any such issues.

[jplatte]

I believe that introducing breaking changes, can have significant implications for production environments. While upgrading dependencies might seem straightforward in smaller projects or development environments, it often requires a more extensive process in larger, production-grade systems.

For sure. I'm not arguing with any of that.

It might be worth considering ways to minimize such impacts in the future, whether through stricter versioning policies or improved communication of potential risks when introducing changes

I'm happy to hear about any ideas towards this. Note that the breaking change being discussed here is extremely subtle: A (private) macro changed what it outputs such that existing uses of the macro in existing versions of other related crates stopped compiling because they were relying on other changes to those related crates that happened in the same PR. I don't think this can really be detected automatically - in particular cargo-semver-checks does not flag anything about axum-core v0.5.1.

[gilgabo]

Thank you very much @jplatte , everything is working perfectly again.

A couple of final comments / thoughts: our pipelines do nothing weird, just a fresh compilation, deployment and some validations, but nothing outside the community standards. For us, making changes is a big deal since our applications provide a large number of services to a large number of users, believing in the stability and reliability of Axum releases, so for us scheduling changes means ceasing to serve part or all of our consumers.

Perhaps in the future it will be very useful consider productive contexts like ours and be sure that the releases that are being generated are backward compatible with previous versions and do not generate breaking changes.

Thank you very much again for you time, effort and help!