-
Notifications
You must be signed in to change notification settings - Fork 10
update protos to latest #60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
WalkthroughThe PR removes a Go listener test file and adds six new generated Swift protobuf files for device sync backup models. It also refactors identity-related Swift protobuf files to use bytecode-based name maps, rename address-based fields to identifier-based terminology, and introduce passkey signature support. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Areas requiring extra attention:
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (4)
swift/identity/api/v1/identity.pb.swift (1)
230-256: Identifier + identifierKind changes for GetInboxIds are wired correctly (note docstring wording)The migration of
GetInboxIdsRequest.RequestandGetInboxIdsResponse.Responseto use:
identifier: StringidentifierKind: Xmtp_Identity_Associations_IdentifierKindis consistently reflected across the struct definitions,
_protobuf_nameMapbytecode,decodeMessage,traverse, and==implementations. Field numbers (1 → identifier, 2 → identifierKind on the request; 1 → identifier, 2 → inbox_id, 3 → identifier_kind on the response) line up correctly, so on-the-wire compatibility is preserved while the Swift API surface moves from “address” to generic identifiers.One minor nit: the surrounding comments still speak about “addresses”; if that’s no longer accurate for the updated proto schema, consider updating the
.protocomments upstream so future regenerations reflect the new terminology here.Also applies to: 259-295, 711-744, 776-817
swift/device_sync/message_backup.pb.swift (1)
3-3: SwiftLint blanket disable in generated fileSince this file is generator‑owned (
// DO NOT EDIT.), theswiftlint:disable allpragma is expected. If the SwiftLint warning is noisy, prefer excluding your generated Swift proto paths in.swiftlint.ymlrather than touching the generated source.swift/identity/associations/association.pb.swift (1)
187-191: Docs still use “address” terminology where fields are now identifier‑basedA few comments (e.g., around
CreateInboxandRevokeAssociation/ChangeRecoveryAddress) still talk about “recovery address” even though the fields have been renamed to identifiers and now support passkeys. Consider updating the proto comments so the generated Swift docs match the new identifier semantics and avoid confusion for consumers.Also applies to: 286-291, 318-321
swift/device_sync/content.pb.swift (1)
1-4: Handle SwiftLint blanket disable via configuration for generated filesSwiftLint is flagging the
// swiftlint:disable alldirective. Since this file is generated (// DO NOT EDIT.), it's better not to change it manually. Instead, consider excluding*.pb.swift(or this path) from SwiftLint in your configuration, or explicitly allowing blanket disables for generated code, so you avoid churn on regenerated files while keeping lint rules strict for hand-written sources.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (58)
integration/gen/notifications/v1/service_pb.d.tsis excluded by!**/gen/**integration/gen/notifications/v1/service_pb.jsis excluded by!**/gen/**pkg/proto/device_sync/consent_backup.pb.gois excluded by!**/*.pb.gopkg/proto/device_sync/content.pb.gois excluded by!**/*.pb.gopkg/proto/device_sync/device_sync.pb.gois excluded by!**/*.pb.gopkg/proto/device_sync/event_backup.pb.gois excluded by!**/*.pb.gopkg/proto/device_sync/group_backup.pb.gois excluded by!**/*.pb.gopkg/proto/device_sync/message_backup.pb.gois excluded by!**/*.pb.gopkg/proto/identity/api/v1/identity.pb.gois excluded by!**/*.pb.gopkg/proto/identity/associations/association.pb.gois excluded by!**/*.pb.gopkg/proto/identity/associations/signature.pb.gois excluded by!**/*.pb.gopkg/proto/identity/credential.pb.gois excluded by!**/*.pb.gopkg/proto/keystore_api/v1/keystore.pb.gois excluded by!**/*.pb.gopkg/proto/message_api/v1/authn.pb.gois excluded by!**/*.pb.gopkg/proto/message_api/v1/message_api.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/ciphertext.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/composite.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/contact.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/content.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/conversation_reference.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/ecies.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/frames.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/invitation.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/message.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/private_key.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/private_preferences.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/public_key.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/signature.pb.gois excluded by!**/*.pb.gopkg/proto/message_contents/signed_payload.pb.gois excluded by!**/*.pb.gopkg/proto/mls/api/v1/mls.pb.gois excluded by!**/*.pb.gopkg/proto/mls/api/v1/mls_grpc.pb.gois excluded by!**/*.pb.gopkg/proto/mls/database/intents.pb.gois excluded by!**/*.pb.gopkg/proto/mls/database/task.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/commit_log.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/content.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/content_types/leave_request.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/content_types/multi_remote_attachment.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/content_types/reaction.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/content_types/wallet_send_calls.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/group_membership.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/group_metadata.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/group_mutable_metadata.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/group_permissions.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/oneshot.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/transcript_messages.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/welcome_pointer.pb.gois excluded by!**/*.pb.gopkg/proto/mls/message_contents/wrapper_encryption.pb.gois excluded by!**/*.pb.gopkg/proto/mls_validation/v1/service.pb.gois excluded by!**/*.pb.gopkg/proto/mls_validation/v1/service_grpc.pb.gois excluded by!**/*.pb.gopkg/proto/xmtpv4/envelopes/envelopes.pb.gois excluded by!**/*.pb.gopkg/proto/xmtpv4/envelopes/payer_report.pb.gois excluded by!**/*.pb.gopkg/proto/xmtpv4/message_api/message_api.pb.gois excluded by!**/*.pb.gopkg/proto/xmtpv4/message_api/message_api_grpc.pb.gois excluded by!**/*.pb.gopkg/proto/xmtpv4/message_api/misbehavior_api.pb.gois excluded by!**/*.pb.gopkg/proto/xmtpv4/metadata_api/metadata_api.pb.gois excluded by!**/*.pb.gopkg/proto/xmtpv4/metadata_api/metadata_api_grpc.pb.gois excluded by!**/*.pb.gopkg/proto/xmtpv4/payer_api/payer_api.pb.gois excluded by!**/*.pb.gopkg/proto/xmtpv4/payer_api/payer_api_grpc.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (12)
pkg/xmtp/listener_test.go(0 hunks)swift/device_sync/consent_backup.pb.swift(1 hunks)swift/device_sync/content.pb.swift(1 hunks)swift/device_sync/device_sync.pb.swift(1 hunks)swift/device_sync/event_backup.pb.swift(1 hunks)swift/device_sync/group_backup.pb.swift(1 hunks)swift/device_sync/message_backup.pb.swift(1 hunks)swift/identity/api/v1/identity.connect.swift(1 hunks)swift/identity/api/v1/identity.pb.swift(18 hunks)swift/identity/associations/association.pb.swift(23 hunks)swift/identity/associations/signature.pb.swift(13 hunks)swift/identity/credential.pb.swift(1 hunks)
💤 Files with no reviewable changes (1)
- pkg/xmtp/listener_test.go
🧰 Additional context used
🧬 Code graph analysis (9)
swift/device_sync/group_backup.pb.swift (1)
swift/device_sync/device_sync.pb.swift (9)
decodeMessage(213-287)decodeMessage(331-344)decodeMessage(380-392)traverse(289-318)traverse(346-364)traverse(394-409)lhs(320-324)lhs(366-373)lhs(411-417)
swift/device_sync/device_sync.pb.swift (2)
swift/device_sync/content.pb.swift (18)
decodeMessage(282-343)decodeMessage(383-393)decodeMessage(413-423)decodeMessage(443-478)decodeMessage(510-520)decodeMessage(540-551)decodeMessage(575-588)decodeMessage(624-639)decodeMessage(683-700)traverse(345-370)traverse(395-400)traverse(425-430)traverse(480-497)traverse(522-527)traverse(553-561)traverse(590-608)traverse(641-665)traverse(702-711)swift/device_sync/group_backup.pb.swift (6)
decodeMessage(343-370)decodeMessage(460-472)decodeMessage(500-510)traverse(372-425)traverse(474-485)traverse(512-517)
swift/identity/api/v1/identity.pb.swift (1)
swift/identity/associations/association.pb.swift (36)
decodeMessage(525-563)decodeMessage(599-610)decodeMessage(638-651)decodeMessage(687-701)decodeMessage(741-754)decodeMessage(790-801)decodeMessage(829-842)decodeMessage(878-939)decodeMessage(979-991)decodeMessage(1019-1030)decodeMessage(1058-1073)decodeMessage(1117-1128)traverse(565-586)traverse(612-624)traverse(653-671)traverse(703-724)traverse(756-774)traverse(803-815)traverse(844-862)traverse(941-966)traverse(993-1004)traverse(1032-1044)traverse(1075-1099)traverse(1130-1138)lhs(588-592)lhs(626-631)lhs(673-680)lhs(726-734)lhs(776-783)lhs(817-822)lhs(864-871)lhs(968-972)lhs(1006-1012)lhs(1046-1051)lhs(1101-1110)lhs(1140-1145)
swift/device_sync/consent_backup.pb.swift (2)
swift/device_sync/content.pb.swift (18)
decodeMessage(282-343)decodeMessage(383-393)decodeMessage(413-423)decodeMessage(443-478)decodeMessage(510-520)decodeMessage(540-551)decodeMessage(575-588)decodeMessage(624-639)decodeMessage(683-700)traverse(345-370)traverse(395-400)traverse(425-430)traverse(480-497)traverse(522-527)traverse(553-561)traverse(590-608)traverse(641-665)traverse(702-711)swift/device_sync/device_sync.pb.swift (6)
decodeMessage(213-287)decodeMessage(331-344)decodeMessage(380-392)traverse(289-318)traverse(346-364)traverse(394-409)
swift/device_sync/event_backup.pb.swift (2)
swift/device_sync/consent_backup.pb.swift (3)
decodeMessage(148-161)traverse(163-177)lhs(179-186)swift/device_sync/device_sync.pb.swift (9)
decodeMessage(213-287)decodeMessage(331-344)decodeMessage(380-392)traverse(289-318)traverse(346-364)traverse(394-409)lhs(320-324)lhs(366-373)lhs(411-417)
swift/device_sync/content.pb.swift (2)
swift/device_sync/consent_backup.pb.swift (2)
decodeMessage(148-161)traverse(163-177)swift/device_sync/device_sync.pb.swift (6)
decodeMessage(213-287)decodeMessage(331-344)decodeMessage(380-392)traverse(289-318)traverse(346-364)traverse(394-409)
swift/identity/associations/signature.pb.swift (1)
swift/identity/associations/association.pb.swift (2)
decodeMessage(525-563)traverse(565-586)
swift/identity/associations/association.pb.swift (1)
swift/identity/api/v1/identity.pb.swift (30)
decodeMessage(305-315)decodeMessage(335-348)decodeMessage(384-394)decodeMessage(414-426)decodeMessage(458-468)decodeMessage(492-495)decodeMessage(511-521)decodeMessage(541-552)decodeMessage(576-586)decodeMessage(606-618)decodeMessage(650-661)decodeMessage(685-695)decodeMessage(715-726)decodeMessage(750-760)decodeMessage(780-792)traverse(317-322)traverse(350-368)traverse(396-401)traverse(428-443)traverse(470-479)traverse(497-499)traverse(523-528)traverse(554-562)traverse(588-593)traverse(620-635)traverse(663-671)traverse(697-702)traverse(728-736)traverse(762-767)traverse(794-809)
swift/device_sync/message_backup.pb.swift (3)
swift/device_sync/consent_backup.pb.swift (3)
decodeMessage(148-161)traverse(163-177)lhs(179-186)swift/device_sync/device_sync.pb.swift (9)
decodeMessage(213-287)decodeMessage(331-344)decodeMessage(380-392)traverse(289-318)traverse(346-364)traverse(394-409)lhs(320-324)lhs(366-373)lhs(411-417)swift/device_sync/event_backup.pb.swift (3)
decodeMessage(128-143)traverse(145-169)lhs(171-180)
🪛 SwiftLint (0.57.0)
swift/identity/api/v1/identity.connect.swift
[Warning] 3-3: Use 'next', 'this' or 'previous' instead to disable the 'all' rule once, or re-enable it as soon as possible`
(blanket_disable_command)
swift/device_sync/group_backup.pb.swift
[Warning] 3-3: Use 'next', 'this' or 'previous' instead to disable the 'all' rule once, or re-enable it as soon as possible`
(blanket_disable_command)
swift/device_sync/device_sync.pb.swift
[Warning] 3-3: Use 'next', 'this' or 'previous' instead to disable the 'all' rule once, or re-enable it as soon as possible`
(blanket_disable_command)
swift/device_sync/event_backup.pb.swift
[Warning] 3-3: Use 'next', 'this' or 'previous' instead to disable the 'all' rule once, or re-enable it as soon as possible`
(blanket_disable_command)
swift/device_sync/content.pb.swift
[Warning] 3-3: Use 'next', 'this' or 'previous' instead to disable the 'all' rule once, or re-enable it as soon as possible`
(blanket_disable_command)
swift/device_sync/message_backup.pb.swift
[Warning] 3-3: Use 'next', 'this' or 'previous' instead to disable the 'all' rule once, or re-enable it as soon as possible`
(blanket_disable_command)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build_image
- GitHub Check: Unit
🔇 Additional comments (13)
swift/identity/api/v1/identity.connect.swift (1)
2-3: Generated client header directives are appropriateUsing
// swift-format-ignore-fileand// swiftlint:disable allon this generated Connect client is reasonable so that formatting/lint tools don’t churn or flag machine‑generated code. No further action needed here despite the SwiftLint blanket‑disable warning.swift/identity/credential.pb.swift (1)
42-45: Bytecode-based name map update looks correctThe switch of
_protobuf_nameMapto theSwiftProtobuf._NameMap(bytecode: ...)initializer forinbox_idmatches the pattern used across the updated protos and should be a no-op behaviorally.swift/device_sync/group_backup.pb.swift (1)
26-524: Group backup generated models are consistent and well-formedThe new
Xmtp_DeviceSync_GroupBackup_*enums and messages follow the standard SwiftProtobuf generation patterns: enum raw values andallCasesare aligned, theGroupSaveCOW storage and optional field handling indecodeMessage,traverse, and==are internally consistent, and the bytecode_protobuf_nameMapdefinitions match the declared fields. No issues spotted for this generated surface.swift/device_sync/event_backup.pb.swift (1)
26-181: Event backup enum and message generation look correct
Xmtp_DeviceSync_EventBackup_EventLevelSaveandEventSaveare wired up consistently: optionalgroupID/iconuse backing optionals with matching decode/traverse/== logic, and the bytecode_protobuf_nameMapmatches the defined fields and numbers. Nothing concerning here for this generated file.swift/identity/api/v1/identity.pb.swift (2)
38-67: Sendable conformance for signature request struct is appropriate
Xmtp_Identity_Api_V1_VerifySmartContractWalletSignatureRequestSignaturebeing declaredSendablematches the other messages in this file and its fields are all value types, so this tightens the concurrency model without introducing obvious safety issues.Please just confirm your Swift version’s concurrency checks pass cleanly (build/tests) after this generator bump.
301-409: Identity message runtime/name-map updates look consistentAcross the various identity API messages (
VerifySmartContractWalletSignatures*,PublishIdentityUpdate*,GetIdentityUpdates*,GetInboxIds*), the switch to bytecode-based_protobuf_nameMapinitializers and the existingdecodeMessage/traverse/==implementations are internally consistent with the declared fields and field numbers. This is in line with the other regenerated SwiftProtobuf surfaces in the PR and doesn’t introduce any obvious behavioral changes.If you haven’t already, it’s worth confirming your SwiftProtobuf runtime and protoc Swift plugin versions match whatever produced these bytecode name maps (e.g., via your build tooling or dependency lockfiles).
Also applies to: 454-575, 602-679, 681-709, 746-774
swift/device_sync/message_backup.pb.swift (1)
26-362: Group message backup enums/message and runtime wiring look consistentThe enums,
GroupMessageSavefields, name maps, decode/traverse logic, and equality implementation all line up and match the patterns used in the other device_sync generated types; I don’t see any wire-compatibility or functional issues here.swift/identity/associations/signature.pb.swift (1)
78-95: Passkey signature type and oneof integration look correct
RecoverablePasskeySignature’s fields, field numbers, and name map align with its decode/traverse implementation, and the new.passkeybranch inXmtp_Identity_Associations_Signaturefollows the same oneof pattern as the existing signature variants. I don’t see any issues with wire format or runtime behavior here.Also applies to: 179-201, 315-357, 399-505
swift/identity/associations/association.pb.swift (1)
26-133: IdentifierKind and passkey support are wired consistentlyThe new
IdentifierKindenum,MemberIdentifieroneof (including.passkey),Passkeymessage, and the identifier/relyingParty fields on CreateInbox, AddAssociation, RevokeAssociation, ChangeRecoveryAddress, and AssociationState all have matching field numbers across name maps, decode, traverse, and equality. The patterns match existing SwiftProtobuf‑generated code, and I don’t see any serialization or runtime correctness issues.Also applies to: 196-228, 266-284, 301-316, 326-355, 465-496
swift/device_sync/consent_backup.pb.swift (1)
25-187: Consent backup enums/message and runtime wiring look good
ConsentTypeSave,ConsentStateSave, andConsentSaveare internally consistent: enum values match their name maps, and the message’s field numbers/types are handled symmetrically in decode/traverse/equality. The deprecatedaddressenum value is preserved correctly for compatibility.swift/device_sync/device_sync.pb.swift (1)
25-199: Backup selection/element/metadata/options definitions are coherent and symmetric
BackupElementSelection,BackupElement(and its oneof),BackupMetadataSave, andBackupOptionsall have consistent field numbers across name maps, decode/traverse, and equality. The repeated enum fields and optional start/end ranges are handled in the standard SwiftProtobuf style, so the wire format and runtime behavior look correct.Also applies to: 205-418
swift/device_sync/content.pb.swift (2)
26-272: Generated message structs and oneofs look consistent with existing device_sync modelsThe message types (
DeviceSyncContent,DeviceSyncAcknowledge,PreferenceUpdates,PreferenceUpdate,V1UserPreferenceUpdate,HmacKeyUpdate,DeviceSyncRequest,DeviceSyncReply,DeviceSyncKeyType) and their oneof-backed accessors follow the same patterns as the otherdevice_syncprotos (including optional backing storage for message fields and explicithas*/clear*APIs). Field names and types line up with the related backup models referenced in the rest of the module, so the public surface looks coherent and ready to use.
278-718: Decode/traverse implementations and oneof handling align with SwiftProtobuf patternsThe
decodeMessageandtraverseimplementations for all types (especially the oneof-driven logic inDeviceSyncContent,PreferenceUpdate, andDeviceSyncKeyType) mirror the established pattern fromdevice_sync.pb.swiftandconsent_backup.pb.swift: inline closures for stack-usage quirks, correcthadOneofValue+handleConflictingOneOfsemantics, and consistent equality comparisons based on the underlying optionals andunknownFields. I don't see any mismatched field numbers or enum/field-type pairs.
Update generated protobuf and gRPC code across Go and Swift to the latest proto definitions
Regenerate protobuf and gRPC artifacts across the repository; add new messages (
PayerReport,NodeSignature, etc.), new RPCs (ReplicationApi.GetNewestEnvelope,PayerApi.GetNodes), add Metadata API and device_sync proto types, and bumpprotoc-gen-gooutput format in multiple Go files.📍Where to Start
Start by reviewing the regenerated Go protobuf/gRPC surface for message API in pkg/proto/xmtpv4/message_api/message_api_grpc.pb.go and the new envelopes types in pkg/proto/xmtpv4/envelopes/payer_report.pb.go.
Macroscope summarized 48c2f4c.
Summary by CodeRabbit
New Features
Refactor
Tests