mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Allow recovery from isValidPath RPCs with an invalid path

Browse source 
Currently, clients cannot recover from an isValidPath RPC with an
invalid path parameter because the daemon closes the connection when
that happens.

More precisely:

  1. in performOp, wopIsValidPath case, ‘readStorePath’ raises an
     ‘Error’ exception;

  2. that exception is caught by the handler in ‘processConnection’;

  3. the handler determines errorAllowed == false, and thus exits after
     sending the message.

This last part is fixed by calling ‘startWork’ early on, as in the patch
below.

The same reasoning could be applied to all the RPCs that take one or
more store paths as inputs, but isValidPath is, by definition, likely to
be passed invalid paths in the first place, so it’s important for this
one to allow recovery.
This commit is contained in:
Ludovic Courtès 2014-03-18 23:17:14 +01:00 committed by Eelco Dolstra
parent f93e97517e
commit 51800e06de
1 changed files with 7 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
src/nix-daemon/nix-daemon.cc
View file

@ -294,8 +294,14 @@ static void performOp(bool trusted, unsigned int clientVersion,
#endif #endif
case wopIsValidPath: { case wopIsValidPath: {
Path path = readStorePath(from); /* 'readStorePath' could raise an error leading to the connection
being closed. To be able to recover from an invalid path error,
call 'startWork' early, and do 'assertStorePath' afterwards so
that the 'Error' exception handler doesn't close the
connection. */
Path path = readString(from);
startWork(); startWork();
assertStorePath(path);
bool result = store->isValidPath(path); bool result = store->isValidPath(path);
stopWork(); stopWork();
writeInt(result, to); writeInt(result, to);