diff options
| author | David Bremner <david@tethera.net> | 2017-02-17 21:28:05 -0400 |
|---|---|---|
| committer | David Bremner <david@tethera.net> | 2017-02-25 21:13:50 -0400 |
| commit | e0b22c139c0a9cd2b7dc5afb96e4ccec4f6b1641 (patch) | |
| tree | 41165690c2c3901c4d19ec3733c265bf36962a56 /test/T640-database-modified.sh | |
| parent | e17a914b77230d942b36639c261c345849fe9d52 (diff) | |
lib: handle DatabaseModifiedError in _n_message_ensure_metadata
The retries are hardcoded to a small number, and error handling aborts
than propagating errors from notmuch_database_reopen. These are both
somewhat justified by the assumption that most things that can go
wrong in Xapian::Database::reopen are rare and fatal. Here's the brief
discussion with Xapian upstream:
24-02-2017 08:12:57 < bremner> any intuition about how likely
Xapian::Database::reopen is to fail? I'm catching a
DatabaseModifiedError somewhere where handling any further errors is
tricky, and wondering about treating a failed reopen as as "the
impossible happened, stopping"
24-02-2017 16:22:34 < olly> bremner: there should not be much scope for
failure - stuff like out of memory or disk errors, which are probably a
good enough excuse to stop
Diffstat (limited to 'test/T640-database-modified.sh')
| -rwxr-xr-x | test/T640-database-modified.sh | 1 |
1 files changed, 0 insertions, 1 deletions
diff --git a/test/T640-database-modified.sh b/test/T640-database-modified.sh index b5b3bc2b..516836b0 100755 --- a/test/T640-database-modified.sh +++ b/test/T640-database-modified.sh @@ -6,7 +6,6 @@ test_description="DatabaseModifiedError handling" add_email_corpus test_begin_subtest "catching DatabaseModifiedError in _notmuch_message_ensure_metadata" -test_subtest_known_broken # it seems to need to be an early document to trigger the exception first_id=$(notmuch search --output=messages '*'| head -1 | sed s/^id://) |