Repository navigation
fix(legacy-ab): align legacy address book peer lookup with new API behavior - #423
Merged
Merged
Conversation
…gistration When a peer is* added to the legacy address book before the device sends its first heartbeat, findOrCreatePeer generates a server-side uuid that differs from the client-reported uuid stored in sysinfos. This causes getLegacyAddressBook to return empty username/hostname/platform because sysinfoMap.get(deviceId) misses. - findOrCreatePeer: order by lastHeartbeat DESC so the heartbeat-created peers record (with the client uuid) is preferred over a stale server-generated one. - getLegacyAddressBook: add a fallback path that, for peers missing sysinfo, looks up all peers records by peers.id and finds the one with a heartbeat, then resolves sysinfo through that record's uuid.
Contributor
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
Align findOrCreatePeer with the new API behavior: non-IP devices must already exist in the peers table (registered via heartbeat) before they can be added to the address book. IP-format devices are still created on demand since they are reached via direct IP and never register through heartbeats. In updateLegacyAddressBook, catch NotFoundException and skip the unregistered device with a warning log instead of failing the entire operation. Remove the fallback sysinfo lookup from getLegacyAddressBook since peers are no longer created with server-generated UUIDs for non-IP devices, making the fallback unnecessary.
hashbk
changed the title
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
2 participants
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.
Summary
findOrCreatePeerwith the new API (address-book-peer.service.ts): non-IP devices must already exist in thepeerstable (registered via heartbeat) before they can be added to the address book; IP-format devices are still created on demandupdateLegacyAddressBook, catchNotFoundExceptionfor unregistered non-IP devices and skip them with a warning log instead of creating a peer with a server-generated UUIDgetLegacyAddressBook(no longer needed since peers are no longer created with server-generated UUIDs for non-IP devices)Problem
The legacy address book's
findOrCreatePeerunconditionally created apeersrecord with a server-generateduuid(viauuidv4()) for any device not found in thepeerstable. This differs from the new API behavior, where non-IP devices must have already registered via heartbeat (ensuringpeers.uuidmatches the client-reporteduuidstored insysinfos).The server-generated
uuiddoesn't match anysysinfos.uuidrecord, causinggetLegacyAddressBookto return emptyusername/hostname/platformfor that peer.Solution
Instead of creating peers on demand with server-generated UUIDs (which led to sysinfo lookup failures), reject non-IP devices that haven't sent a heartbeat — consistent with the new API. IP-format devices are still created automatically since they are reached via direct IP and never register through heartbeats.
When updating the legacy address book, devices that fail this check are skipped with a warning log, allowing the remaining valid devices to be synced successfully.