Migrate thread participants to the generated ThreadParticipant model - #6620
Draft
gpunto wants to merge 2 commits into
Draft
Migrate thread participants to the generated ThreadParticipant model#6620gpunto wants to merge 2 commits into
gpunto wants to merge 2 commits into
Conversation
Contributor
PR checklist ✅All required conditions are satisfied:
🎉 Great job! This PR is ready for review. |
Contributor
SDK Size Comparison 📏
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Goal
Migrate thread participants from the hand-written
DownstreamThreadParticipantDtoto the generatedThreadParticipantmodel, together with the null-collection handling the v1 endpoints require for it to parse.Part of AND-1291
Implementation
The generated models come from the v2 spec, whose encoder writes nil Go maps and slices as
{}and[], so their collection properties are non-null. We call the v1 endpoints, whose encoder writesnullinstead:POST /threadssends"custom": nullon everythread_participantsentry.NullCollectionsAsEmptyFactory, which reads an explicitnullas an empty collection for the non-nullListandMapproperties of the generated network models. It only claims classes in thenetwork.modelspackage that declare such a property, and is registered last so the model-specific adapters keep precedence and delegate into it.ThreadParticipantandUserResponse, plusUserResponseAdapterfor the user's flattened custom data; remove the hand-writtenDownstreamThreadParticipantDto.thread_participantsonDownstreamThreadDtoandDownstreamThreadInfoDtoand map it to the domainThreadParticipantinDomainMapping. The message-levelthread_participantsis a list of users rather than participants, soDownstreamMessageDtois unchanged.Testing
NullCollectionsAsEmptyFactoryTest: an explicit null becomes an empty collection, an absent key still falls back to the model default, populated collections are read unchanged, and hand-written DTOs are left alone.ThreadParticipantParsingTestparses a payload captured fromPOST /threads. Removing the factory registration makes it fail withNon-null value 'custom' was null at $.custom.queryThreadson the wire: 10 threads and 22 participants parsed, the parsed count matchedparticipantCounton every thread, and per-user custom data was collected correctly.spotlessApply,detekt,apiCheck(no public API change) and the fullstream-chat-android-clientunit test suite.