"TL;DR: Always set a deadline.", https://grpc.io/blog/deadlines/
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clangd/index/remote/Client.cpp | ||
---|---|---|
63 | I fear this may be too short - experience is going to be bad if it's really slow, but cutting off requests isn't going to be great. (If the connection is actually down, we shouldn't end up waiting for the deadline anyway in general: fail-fast is the default for grpc. https://github.com/grpc/grpc/blob/master/doc/wait-for-ready.md) | |
95 | nit: I'd suggest generally avoiding const on non-pointer members, it messes with move semantics. (In this case the object is always wrapped in unique_ptr before being exposed publicly, so it's actually fine. But have seen enough cases where it's initially fine and later not that I personally prefer to just always avoid it) |
I fear this may be too short - experience is going to be bad if it's really slow, but cutting off requests isn't going to be great.
I'd suggest bumping this up to at least a second... we should be sure we're logging timeouts too.
(If the connection is actually down, we shouldn't end up waiting for the deadline anyway in general: fail-fast is the default for grpc. https://github.com/grpc/grpc/blob/master/doc/wait-for-ready.md)