- As blocking is now reciprocal, we do not need another query, we can
use neo4j-graphql-js magic to query for a BLOCKED relationship between
the postAuthor and the currentUser
We had this error in our neo4j pod recently:
```
2019-12-02 08:29:42.680+0000 ERROR Unable to schedule bolt session 'bolt-1018230' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
2019-12-02 08:29:42.680+0000 ERROR Unable to schedule bolt session 'bolt-1018224' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
2019-12-02 08:29:42.681+0000 ERROR Unable to schedule bolt session 'bolt-1018352' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
2019-12-02 08:29:42.682+0000 ERROR Unable to schedule bolt session 'bolt-1018243' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
```
Apparently the default is 400 threads. So we must have a leak somewhere.
Since we decided to open Human Connection for public registration, we
don't need to create artificial shortage of signups. The original
intention here was too:
1. Grow the network slowly and under control
2. Create an incentive for users to invite their friends
Point 2 is now obsolete, everyone can signup herself. Point 1 is based
on the (seemingly) wrong assumption that there will be a "run" on the
network if we open it for public registration. Our growth was fairly
stable so far.
Ideally we would not have this inconsistent edge case that we filter
through the user type. Much better would be a graphql query like:
```graphql
{
User(filter: { primary_email: { email: "something@example.org" } }) {
id
name
slug
}
}
```
- following @roschaefer's PR review suggestions
- simplify UpdatePost by using pinPost/unpinPost
- did not remove filtering because attempting to have two queries caused
problems as well to do with duplicate records, etc... and it's working
now
- at the moment, it is created as a property of Post, but will be
refactored to create a relationship[:PINNED] from the admin to the Post
- Co-authored-by: kachulio1 <jngugi88@gmail.com>
I think the validation for categories was too complex and the graphql
query 'PostEmotionsByCurrentUser' was erroneously allowed for
unauthenticated users.
