| 1 | | Okay, I've been looking into this, and I see that in fact this kind of corruption ''is'' handled, by logging it, accounting for it in a count called `corrupt-shares`, and skipping the corrupted share. See [source:trunk/src/allmydata/storage/expirer.py?annotate=blame&rev=d5651a0d0eebdc144db53425ee461e186319e5fd#L127 exporer.py]. The only reason that we've thought it was ''not'' being handled all these years is because it calls `twisted.python.log.err()`, which emits a string to the twistd.log that says {{{"Unhandled Error"}}}, plus a stack trace. So I propose that we just remove that call to `twisted.python.log.err()` and add a unit test which requires the code under test to detect and skip over corrupted shares ''without'' emitting this error log. |
| | 1 | Okay, I've been looking into this, and I see that in fact this kind of corruption ''is'' handled, by logging it, accounting for it in a count called `corrupt-shares`, and skipping the corrupted share. See [source:trunk/src/allmydata/storage/expirer.py?annotate=blame&rev=d5651a0d0eebdc144db53425ee461e186319e5fd#L127 expirer.py]. The only reason that we've thought it was ''not'' being handled all these years is because it calls `twisted.python.log.err()`, which emits a string to the twistd.log that says {{{"Unhandled Error"}}}, plus a stack trace. So I propose that we just remove that call to `twisted.python.log.err()` and add a unit test which requires the code under test to detect and skip over corrupted shares ''without'' emitting this error log. |
