- 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.
I think it makes more sense to update an existing notification in place.
Ie. if there was already a notification, just mark it as unread so it
ends up in the recipient's notification list again.
Note that we don't create duplicate notifications. I made use of the behaviour
of XSS-middleware: It removes all css classes from `<a>` anchors. Because
notifications rely on a css class `mention` which gets removed in a later
middleware, this gives us a nice behaviour for re-notifications without creating
duplicates. The downside is that it creates dependencies between middlewares and
it's not that obvious at all.
cc @mattwr18 @ulfgebhardt @appinteractive @Tirokk
