⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 40.00000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.13%. Comparing base (bbed2c0) to head (4cfb1e7).
⚠️ Report is 263 commits behind head on develop.

@@           Coverage Diff            @@
##           develop    #3574   +/-   ##
========================================
  Coverage    93.13%   93.13%           
========================================
  Files           68       68           
  Lines        15336    15421   +85     
========================================
+ Hits         14283    14363   +80     
- Misses        1053     1058    +5     

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

The issue you linked points to the shape being boxed long, which means it is a nullable int in python. This suggests that we have a bug.

I'd hope that we can do a few things to move this forward, but it may be asking too much, so I'm open to some discussion to make sure we can move this forward at a reasonable rate:

1. We need to add tests. Ideally this comes in the form of upstream additions to the protocol tests for all protocols that support the box trait. That may be all of them, we will need to find a definition of what the box trait does to confirm.
2. We should make sure this works for all protocols and primitive types, not just integers in RestJson. This likely requires more code changes to ensure all of our _handle* methods can accept a null when it's marked as box.
3. We have encountered some issues in the past with our parsers being too lenient, we should keep this change impacting as few shapes as possible. Instead of always supporting nulls for shapes modeled as integers/longs, what do you think of changing the logic so that it only accepts null as a valid value if the shape is modeled as box, and keeping the logic the same otherwise?