When deserializing JSON, accept both int and string in 'intValue'

[RazvanRotari]

Fixes #1905
Design discussion issue (if applicable) #

Changes

When deserializing JSON, accept both int and string in 'intValue' field of AnyValue.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: RazvanRotari / name: Razvan Rotari (342e209, b78cc01, 96254ab, f0fd0e7)
• ✅ login: TommyCpp / name: Zhongyang Wu (c702dc1)
• ✅ login: lalitb / name: Lalit Kumar Bhasin (e93b5f0, 0d4f174)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.9%. Comparing base (a9b8621) to head (e93b5f0).

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1906     +/-   ##
=======================================
- Coverage   74.9%   74.9%   -0.1%     
=======================================
  Files        122     122             
  Lines      20311   20311             
=======================================
- Hits       15217   15216      -1     
- Misses      5094    5095      +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lalitb]

@RazvanRotari Thanks for the PR. Can you also add tests to validate this? There are some relevant unit-tests here - test_serde if that helps.

[RazvanRotari]

@lalitb Modified test_serde to check for this case.

[pravic]

@lalitb Hi guys, any updates on this? We also have encountered this problem.

[pravic]

@lalitb @cijothomas Looks like the latest cc crate can't be built with rustc 1.65. Should it be fixed (pinned, I assume?) here or in a separate PR?

[lalitb]

Thanks @RazvanRotari . Nicely done. LGTM.

[lalitb]

@lalitb @cijothomas Looks like the latest cc crate can't be built with rustc 1.65. Should it be fixed (pinned, I assume?) here or in a separate PR?

I think it was fixed in #1924