[tahoe-lafs-trac-stream] [tahoe-lafs] #1670: KeyError in mutable retrieve

[tahoe-lafs]

#1670: KeyError in mutable retrieve
-------------------------+-------------------------------------------------
     Reporter:  vikarti  |      Owner:  zooko
         Type:  defect   |     Status:  new
     Priority:           |  Milestone:  1.9.2
  critical               |    Version:  1.9.0-s3branch
    Component:  code-    |   Keywords:  mutable retrieve error tahoe-backup
  mutable                |  regression
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by zooko):

 * version:  1.9.1 => 1.9.0-s3branch


Comment:

 Hm, actually this may be the same underlying problem as in #1669. In
 #1669, we found that:

 •
 [source:git/src/allmydata/mutable/layout.py?annotate=blame&rev=87ca4fc7055faaea7e54cbab4584132b021e42e1#L433
 SDMFSlotWriteProxy.get_verinfo] and
 [source:git/src/allmydata/mutable/layout.py?annotate=blame&rev=87ca4fc7055faaea7e54cbab4584132b021e42e1#L1692
 MDMFSlotReadProxy.get_verinfo] return the same shape of tuple, but
 [source:git/src/allmydata/mutable/layout.py?annotate=blame&rev=87ca4fc7055faaea7e54cbab4584132b021e42e1#L1102
 MDMFSlotWriteProxy.get_verinfo] returns a different shape.

 So, could this ticket (#1670) be caused by
 {{{MDMFSlotWriteProxy.get_verinfo}}} returning a differently-shaped
 verinfo, which gets used as a key in the {{{Retrieve}}}, and then later
 when {{{MDMFSlotReadProxy.get_verinfo}}} returns what ought to be the same
 thing (but isn't due to the different shape), and then the {{{Retrieve}}}
 looks it up in the {{{versionmap}}}, it gets a key error?

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