Skip to content
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

Account deletion/migration: user is unknown on the pod #72

Open
cmrd-senya opened this issue Aug 11, 2017 · 2 comments
Open

Account deletion/migration: user is unknown on the pod #72

cmrd-senya opened this issue Aug 11, 2017 · 2 comments

Comments

@cmrd-senya
Copy link
Member

cmrd-senya commented Aug 11, 2017

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.


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@SuperTux88
Copy link
Member

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 ;)

@SuperTux88
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants