@tsmathis if you can check that the new serde's don't impact builds, that would be super helpful! The existing logic shouldn't have changed for the serdes.

I had to add a couple of catches for when subfields are partially deserialized already

Codecov Report

❌ Patch coverage is 78.78788% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.96%. Comparing base (7c9bb94) to head (5879006).

@@             Coverage Diff             @@
##           develop    #1372      +/-   ##
===========================================
- Coverage    85.97%   85.96%   -0.01%     
===========================================
  Files          229      229              
  Lines        17873    17888      +15     
===========================================
+ Hits         15366    15378      +12     
- Misses        2507     2510       +3     

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

Missed the tag yesterday, will take a look first thing tomorrow!

Do you encounter an issue with the (de)serialization behavior in the electrode_adapter module?

Yeah in the client - if you switch between develop and this branch, you'll probably hit issues doing a full download of the insertion_electrodes endpoint with develop but (ideally) not with these changes. Think it's a minor roundtrip thing because of the client running MontyDecoder().process_decoded --> pydantic schema on these

Personally I'm fine with removing the monty decoding from the client, especially since we're building the schemas to de-/serialize correctly without it

I would prefer removing the monty decoding from the client then. I'd rather we make it a goal to not pollute the emmet implementations as much as possible.

And as you said, what we've done with the models/types for serialization(model_dumping) to avoid jsanitize should also be implicitly removing the need for monty decoding during deserialization on the client?

OK I'll revert the serde changes here and see about removing the monty decoder logic from the client

The updated changes for the (de)serialization functions seem fine to me 👍

Question though, for the serialize=False on GrainBoundary, StructureGraph, and MoleculeGraph, are the structure/molecule fields for those pymatgen classes not supposed to be the corresponding pymatgen objects?

Question though, for the serialize=False on GrainBoundary, StructureGraph, and MoleculeGraph, are the structure/molecule fields for those pymatgen classes not supposed to be the corresponding pymatgen objects?

They are, but because they're deserialized through an as_dict (the target_cls.from_dict(graph) line), the as_dict also expects the Structure to be in its dict representation, not a Structure

Gotcha, makes sense 👍