Opened at 2008-08-19T18:46:52Z
Last modified at 2011-07-23T18:41:08Z
#501 assigned defect
NotMutableError (now NotWriteableError) escaping into the twistd.log
Reported by: | zooko | Owned by: | davidsarah |
---|---|---|---|
Priority: | major | Milestone: | undecided |
Component: | code-encoding | Version: | 1.2.0 |
Keywords: | error logging | Cc: | |
Launchpad Bug: |
Description
2008-08-13 17:23:27.831Z [-] Unhandled Error Traceback (most recent call last): Failure: allmydata.mutable.common.NotMutableError:
I guess this means that somewhere we aren't handling errback where we should.
Change History (7)
comment:1 Changed at 2010-03-25T00:41:01Z by davidsarah
- Keywords error logging added
comment:2 Changed at 2011-07-23T01:52:20Z by davidsarah
- Owner set to zooko
comment:3 Changed at 2011-07-23T03:28:29Z by zooko
- Status changed from new to assigned
comment:4 follow-up: ↓ 5 Changed at 2011-07-23T06:10:21Z by zooko
- Resolution set to fixed
- Status changed from assigned to closed
NotMutableError no longer appears in our source tree.
comment:5 in reply to: ↑ 4 Changed at 2011-07-23T18:40:55Z by davidsarah
- Resolution fixed deleted
- Status changed from closed to reopened
- Summary changed from NotMutableError escaping into the twistd.log to NotMutableError (now NotWriteableError) escaping into the twistd.log
Replying to zooko:
NotMutableError no longer appears in our source tree.
That's because it was renamed to NotWriteableError in 6057bc02cc33b5b7. (It is raised also when an attempt is made to write to a readonly mutable object.)
We should check whether an unhandled NotWriteableError occurs in the logs of a gateway when trying to write an immutable or readonly file/directory.
Version 0, edited at 2011-07-23T18:40:55Z
by davidsarah
(next)
comment:6 Changed at 2011-07-23T18:41:02Z by davidsarah
- Owner changed from zooko to davidsarah
- Status changed from reopened to new
comment:7 Changed at 2011-07-23T18:41:08Z by davidsarah
- Status changed from new to assigned
Note: See
TracTickets for help on using
tickets.
This was reported a long time ago, and no context was given about what was happening around the above log message. Can we reproduce it?