Skip to content

Allow structure members to be serialized as explicit nulls - #1390

Open
timocov wants to merge 2 commits into
smithy-lang:mainfrom
timocov:explicit-null-for-members
Open

timocov wants to merge 2 commits into
smithy-lang:mainfrom
timocov:explicit-null-for-members

Conversation

@timocov

@timocov timocov commented Oct 8, 2026

Copy link
Copy Markdown
Contributor

What behavior changes?

By default no behavior changes. Opt-in: a symbol provider now can say if a structure member should be serialized as explicit null instead of nothing as it is right now.

Why is this change needed?

We're migrating to Smithy and it is working very well, but unfortunately due to the previous setup we had, a couple of public APIs we expose returned certain values as explicit nulls and this is something our consumers rely on and will treat omitting values as a "breaking change" (which we're happy to do, but it requires quite long lead time which will stop us from migrating to smithy until then). I was trying to overcome this otherwise in our codegen integration with available injection points, but this requires quite a lot of changes: the solution I was thinking was to override a structure containing such fields serialization calls (basically for structure Payload > structure Data > "field with explicit null" we would need to override serialization of Data inside Payload so that it wraps the data struct into a wrapper class that serializes members of the original struct + goes over all "nullable" fields and checks if they are nulls and then writes explicit nulls). So I was thinking if you're fine with having support for this new feature inside the codegen (it is similar to @sparse for collections, but for structure members).

How was this validated?

  • Run tests
  • pTML locally and then installed in our integration package and run tests
  • Added usage of new symbol property and validated that the value of fields is in fact being serialized as explicit null

Please note that I had to run tests with 27ff34d as a base because current main has broken deserailization - see #1358 (comment).

What should reviewers focus on?

I also moved a common "logic" of writing explicit null into SerializerMemberGenerator since it felt like the right place for this (we need to know the schema variable and it handles it already; and it kinda did handle list/map members already for schema detection).

Additional Links

Nothing.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

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.

1 participant