- start refactoring
- locations does not have any automated tests, which makes it more
difficult to refactor and have confidence that functionality will not be
broken
- notificationsMiddleware in progress
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.
@KapilJ your solution is right now the best solution, I think. Probably
the ideal solution would be if we could implement the `CreateComment`
resolver in such a way that it is doing eager loading of the
`comment->post->author` relationship and resolving a commment object
which has the required objects all set. Then you wouldn't have to
refetch all the stuff.
But I think this is OK for now 👍
- when a user updates a post, we should not override every property in
our database with the new params, since we have read-only properties
like createdAt that we don't want to go deleting aimlessly.
