search

sweet-sh / sweet-web

A lightweight, trust- and community-based social network
GNU Affero General Public License v3.0
21 stars 2 forks source link

Inconsistent community membership behavior #21

Closed toBeOfUse closed 5 years ago

toBeOfUse commented 5 years ago

comm This behavior can be reproduced if we make a user, have them join a community, and then manually delete the community from the user's document's "communities" array in the database, while leaving the user in the community's document's "members" array: the user can make posts in the community and can technically comment but doesn't see the posts on their home page and doesn't get the comment form in the community feed. So, there may be a weird database problem where the user got added to the community's list but not the other way around because the server got reset before that part happened (looking at the code, they would happen in that order), or there may be a bug in the code that I'm not seeing? I think this stuff is only changed in communityRoutes.js and it seems... pretty simple. I guess this is an inherent danger of storing this kind of information in two places, I'm not sure I really see the advantage, especially if we're doing stuff like populating the myCommunities array in the showposts request function like Community.find({ members: loggedInUserData._id }) (routes.js L900) anyway. Like, if we are going to have a list of communities in the users' documents we should be using it there. Anyway database integrity tests are in order.

toBeOfUse commented 5 years ago

For the record (literally,) I was right about the database integrity issues thing but we don't know what caused them. Hopefully it was just a bug in the earlier version of the code which is now fixed. Or the server got restarted after the field was changed in the community document but before it was changed in the user document... on 17 separate occasions. Or there's a really weird bug in the current code, or there's a problem with the database software/system. Anyway, this specific issue is fixed, especially if we rerun databaseIntegrityCheck.js periodically going forward, so I'm closing it for now.