You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is an edge case, when we receive AccountDeletion or AccountMigration message with author that isn't discovered. Currently diaspora_federation will run the discovery procedure and then receive the entity, just how it works for any other message type. But it doesn't make too much sense for both AccountDeletion and AccountMigration. Since we don't know the author, then we don't have to delete anything or update references on our pod. So we should just ignore these messages for the case, when author is not discovered. This will save us from doing unnecessary job. So while it is not what normally happens (reception of AD/AM message for undiscovered user) I think it worth adding additional handling for this case, since it's possible that other implementations go this way for any reason.
This is a really small optimization. If the old user is fetchable, it will fetch it, and process the entity quickly, because nothing is to do. If the old user isn't fetchable, it will fail 10 times like every other message with an unfetchable author too. So probably every other message received probably creates more load on the server than a AccountMigration with an unknown old author.
It's also not that easy, because the discovery process is triggered from diaspora (the gem-user) and not the gem itself, so we would need to add a flag for "give me the key if you have it, but don't fetch it" to the callbacks.
I keep this issue, but it's a small optimization for a problem that normally never happens that isn't just a quickfix and even needs API-changes ... so really low priority ;)
The priority maybe changes, when we start sending profile updates, close and migration messages to more than just the contacts, because it happens more often then. But even then, the person is probably already known, because the pod received a profile update before. And if not, it still doesn't use a lot of resources compared to what a pod needs to handle anyway.
There is an edge case, when we receive
AccountDeletion
orAccountMigration
message withauthor
that isn't discovered. Currentlydiaspora_federation
will run the discovery procedure and then receive the entity, just how it works for any other message type. But it doesn't make too much sense for bothAccountDeletion
andAccountMigration
. Since we don't know the author, then we don't have to delete anything or update references on our pod. So we should just ignore these messages for the case, whenauthor
is not discovered. This will save us from doing unnecessary job. So while it is not what normally happens (reception of AD/AM message for undiscovered user) I think it worth adding additional handling for this case, since it's possible that other implementations go this way for any reason.Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: