Update async-graphql bounds to require 7.0.17#198
Conversation
ZohebShaikh
left a comment
There was a problem hiding this comment.
The aforementioned issue in async-graphql has been fixed by this PR
tpoliaw
left a comment
There was a problem hiding this comment.
The version of graphql being used (pinned in the lockfile) was already 7.0.17 after #187. The change to Cargo.toml to make it the minimum requirement is good, but none of the changes to the lock file here are related and probably shouldn't be in the PR.
cargo generate-lockfile updates everything to the latest version. For this change, it's probably easiest to use cargo build and it will only update the things that have changed (and need updating) in the Cargo.toml file - in this case nothing.
Renovate should open a PR tomorrow with all the patch updates (#190).
|
The other motivation for this PR was ..The https://numtracker.diamond.ac.uk/graphiql is stuck at Loading... for me So I was wondering this might fix it ...Is it just me or are you able to see the GraphIQL ? |
|
It should have already been fixed given we're using the new version (and it does work running locally) but the deployed version was from before the update was merged. Might be time for a 1.0.1 release. |
7.0.17 and cargo lockfile7.0.17
async-graphqlhad a bug in7.0.16which is fixed in7.0.17. I have update this dependecy and then generate the cargo lock file usingcargo generate-lockfile. I have test that the GraphiQL is working as expected.As the lockfile is a generated file that's why it has lots of package update changes included.
ps: 7.0.17 means
>=7.0.17,<8.0.0Having the depedency on7.0.16would be okay as it will update to the latest which is7.0.17but our release process depends on the lock file so it is better to point to the version which has the fix