[tahoe-lafs-trac-stream] [tahoe-lafs] #1758: tahoe check on LIT produces KeyError

[tahoe-lafs]

#1758: tahoe check on LIT produces KeyError
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  davidsarah
  kmarkley86             |     Status:  assigned
         Type:  defect   |  Milestone:  1.10.0
     Priority:  normal   |    Version:  1.9.1
    Component:  code     |   Keywords:  check deep-check lit immutable
   Resolution:           |  error reviewed
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 Replying to [comment:4 davidsarah]:

 > There are two ways to fix the bug:
 >
 > a) include {{{"summary"}}}, {{{"count-shares-*"}}}, {{{"list-corrupt-
 shares"}}} fields in the output even for LIT files/dirs;
 >
 > b) make '{{{tahoe check}}}' tolerate lack of these fields.
 >
 > Arguably, {{{"summary"}}} makes sense for LIT files and the other fields
 do not, but that doesn't really help a lot in choosing between a) and b).
 Any preference? I have a patch for b) but it seems slightly ugly to do it
 that way.

 Yeah, I didn't want to add non-sensical fake information (like pretending
 that LIT files have one share that's always present, or suggesting that
 LIT files have shares at all). It might be ok to have LIT results return
 empty lists and share-counts of "0", but it'd be confusing and somewhat
 scary if the renderer shows those numbers in the same way it shows them
 for CHK and SSK files ("huh? oh no! zero shares?!? Oh, wait, right,
 LIT."). So we'd want the renderer to not display share-counts/etc for LIT
 files. Which means we need special-casing code in the renderer anyways.
 And that code could switch on the file being of type "LIT", but that's
 disappointingly hard-coded (*any* filetype that doesn't use shares should
 get the special-case code, not just LITs, it's just that so far LITs are
 the only non-distributed filetype). So the code should probably switch on
 things like {{{res["list-corrupt-shares"] is None}}} or {{{"list-corrupt-
 shares" not in res}}}.

 So I guess I'd lean +0 towards (b), and have the '{{{tahoe check}}}'
 renderer tolerate missing fields (by not printing anything about them).

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1758#comment:11>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage