Hi, It is by design that nested docs have to be updated as a block including all children on every update.
So if we are to support atomic update on a leader ID, then the atomic update logic would need to fetch also all children and reconstruct the entire block before committing. From your experience it obviously does not, so I assume it is a corner case / interaction case that noone experienced before. I have not checked the code or docs. Documenting this limitation sounds like a sound thing to do as a first step. Jan > 5. aug. 2026 kl. 16:26 skrev [email protected]: > > Hello Solr users, > > I believe I found an unexpected behavior when using atomic updates with > nested documents. > > I am using Solr nested documents and noticed that performing an atomic update > on a parent document removes its child documents. > > I created a minimal example here: > > https://gist.github.com/DarioViva42/c3de6142e7dd892f4279b1d62a275a35 > > To reproduce the example, first run AddDocument.java and then > UpdateDocument.java > > Observations: > > - For 001, atomic updates (e.g. field changes) work normally. > - For 002, the age increment works correctly. > - However, after the update, the nested child document 003 is gone. > > After the update the child document is no longer present. > > Is this expected behavior/limitation of atomic updates with nested documents, > or should this be considered a bug? I would have expected that the child > documents stay. > > If it is intended, I think it would be worth documenting clearly, since it is > easy to accidentally remove nested documents with a seemingly safe atomic > update. > > Thanks, > Dario
