Users will get redirected to the login page and will see a 'restricted'
page after logging in again.
See frontend: ConnectionManager.reportConnectionError
ioredis may reuse the error instance for multiple callbacks. E.g. when
the connection to redis fails, the queue is flushed with the same
MaxRetriesPerRequestError instance.
See the docs of OError.tag:
https://github.com/overleaf/o-error#long-stack-traces-with-oerrortag
(currently at 221dd902e7bfa0ee92de1ea5a3cbf3152c3ceeb4)
I am tagging all errors at each async hop. Most of the controller code
will only ever see already tagged errors -- or new errors created in
our app code. They should have enough info that we do not need to tag
them again.
...and fix the stubbing of `io.sockets.clients`.
We were running the assertions prior to the actual completion of the
leaveProject. Which in turn shadowed the broken test setup --
`io.sockets.clients()` was returning the `this.clientsInRoom=[]` from a
previous context.
```
result = Promise.all([<Promise that rejects eventually>]) # rejection 1
result.then () -> RoomEvents.emit(eventName) # rejection 2
result.catch (err) -> RoomEvents.emit(eventName, err) # handle r1
```
As shown above, the second rejection remains unhandled. The fix is to
chain the `.catch()` onto the `.then()` Promise.
Sinon does not check the contents of the passed error when checked via
sinon.stub().calledWith.
```
callback = sinon.stub()
callback(new Error("some message"))
.calledWith(new Error("completely different message"))
=== true
```
Cherry-pick plus an additional patch for the joinProject bail-out.
(cherry picked from commit d9570fee70701a5f431c39fdbec5f8bc5a7843fe)
Also drop dead code:
- user_id bailout
There is a check on a completed joinProject call now. It will always
set a user_id, see Router.coffee which has a fallback `{_id:"..."}`.
- late project_id bailout
WebsocketLoadBalancer.emitToRoom will not work without a project_id.
We have to bail out before the call.
frontend -> real-time and doc-updater -> real-time should be in sync.
Otherwise we can send a payload to doc-updater, but can not receive the
confirmation of it -- and the client will send it again in a loop.
Also log the size of the payload.
bail out early on -- especially do not push the update into redis for
doc-updater to discard it.
Confirm the update silently, otherwise the frontend will send it again.
Broadcast a 'otUpdateError' message and disconnect the client, like
doc-updater would do.
Then, don't send new chat messages and new comments to those restricted clients.
We do this because we don't want to leak private information (email addresses
and names) to "restricted" users, those who have read-only access via a
shared token.
