Skip to content

Conversation

danwilliams
Copy link

This fixes the conflict introduced by json-patch 3.1.0.

Motivation

See #1700.

Solution

Changed Cargo.toml to have tighter versions, to prevent the latest version of json-patch being used, which introduces a later version of jsonptr than is expected.

Note that the versions don't need pinning, just tightening.

Note also that they have been set to the last-known working versions, rather than the latest versions. These can be updated at leisure later, when appropriate.

This fixes the conflict introduced by json-patch 3.1.0.

Signed-off-by: Dan Williams <dan@pncr.io>
@danwilliams danwilliams force-pushed the bugfix/json-patch-version branch from 9859639 to c1084d2 Compare February 24, 2025 12:40
@@ -58,9 +58,9 @@ hyper-rustls = { version = "0.27.1", default-features = false }
hyper-socks2 = { version = "0.9.0", default-features = false }
hyper-timeout = "0.5.1"
hyper-util = "0.1.9"
json-patch = "3"
json-patch = "3.0.1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this actually a tighter bound? i'm pretty sure this is ignored on the app side. you'd have to pin with ^ afaikr

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is tighter, due to server rules - Cargo won't update it to 3.1 🙂

I first tried with pinning it, verified that this fixed the issue, and then removed the pin to just specify the minimum required version - this still works (verified locally) and it will allow patch updates but not minor version updates.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, ok. well, if it works. right now CI is massively red.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I must admit I don't have time to look into that at present - as all I've done is set the versions, and that fixes the problem locally, that should be sufficient (or useful for anyone else looking at this perhaps). If there is no other fix later then I could take a deeper look, but you may well decide to upgrade to the latest version instead of fixing to the older one 🙂

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at CI logs, it seems that build is pulling in jsonptr v0.7.1 regardless of our preference. I guess if they use it, we will have to use the one they use anyway.

Copy link
Member

@clux clux Feb 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In related news, 3.1.0 was yanked and 4.0.0 was released, (due to this issue) so probably will give this a day or two, then update manually.

I see they are also re-exporting jsonptr now so we can stick to pinning one dep.

@clux
Copy link
Member

clux commented Mar 11, 2025

replaced by #1718

@clux clux closed this Mar 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants