| Age | Commit message (Collapse) | Author |
|
Check for (non)-crash.
|
|
Code is taken from the API docs, with the twist that the underlying
database is closed. Not crashing is the main point.
|
|
These are strictly to watch for crashes, so don't be too fussy about
the actual timestamps.
|
|
This is returning explicitely cached data, so no database access is needed.
|
|
This is similar to the case of toplevel messages. Currently everything
is cached, so no database access is necessary. This might change in
the future, but it should not crash in either case.
|
|
Include a test for the previously omitted non-trivial code path for
notmuch_thread_get_replies.
|
|
This is returning cached info, so does not need to access the (closed)
database.
|
|
This is just cached data, so as long as we don't prematurely free
anything, it should be fine.
|
|
As with other void API entries, not crashing counts as success.
|
|
At least these exceptions are caught.
|
|
Exception handling matches notmuch_query_search_threads, at least for
this case.
|
|
At least this exception is caught.
|
|
This relies on the change to not tear down the auxilary Xapian
objects, in particular the query parser, when the database is closed.
|
|
We just want to make sure accessing the query owned by a closed db
does not cause a crash.
|
|
|
|
Current functionality is too trivial to really justify a test, but
it's simpler just to test the complete API.
|
|
Start a new file of tests, to keep to the (emerging) scheme of one
notmuch_foo group per file
|
|
This is for consistency with the recently added tests for
notmuch_database_*.
|
|
Since Emacs 27 'mml-secure-epg-sign' errors out if we don't opt-in to
signing as the sender using 'mml-secure-openpgp-sign-with-sender'.
|
|
The goal of this abstraction was to save space. But that failed as
the result actually was that four trivial lines got replace with 15
fairly complicated lines. The opposite of what it was supposed to
do.
Also it made it harder to come up with the fix in the previous commit;
simply grepping for the relevant symbols did not work because they get
constructed at run-time instead of appearing in the source file.
|
|
Starting with Emacs 27 undeclared variables in evaluated interactive
code uses lexical scope. This includes code passed with '--eval' as
we do in the Emacs tests, which also happen to assume dynamic scope.
- This can affect variables defined by libraries that we use. We
let-bind such variables to change the behavior of functions which we
then call with these bindings in effect. If these libraries are not
loaded beforehand, then the bindings are lexical and fail to have
the effect we intended.
At this time only 'smtpmail' has to be loaded explicitly (for the
variables let-bound in emacs_deliver_message and emacs_fcc_message).
'message' doesn't have to be loaded explicitly, because loading
'notmuch' (in 'run_emacs') already takes care of that, indirectly.
- Our own testing-only variables also have to be declared explicitly.
We should have done that anyway, but because of how and where these
variables are used it was very easy to overlook that (i.e. it isn't
something the byte-compiler ever looks at). Not so in Emacs 27
anymore; here this oversight caused four tests to fail.
The numeric values of these variables get incremented by functions
that we add to hooks that are run by many tests, not just the tests
where we actually inspect the value and therefore take care to let-
bind the values to 0 before we begin. The global values therefore
have to be numeric values as well. I have chosen -100 instead of 0
as the default in case someone writes a test that inspects the value
but forgets to let-bind the value. I hope that the unusual negative
value that one is going to see in such a case will help debugging
the issue.
|
|
Xapian exceptions are swallowed and turned into default return value.
|
|
The catch block either needs to return, or the function needs to
return "status". Choose the latter for consistency with
n_d_get_config.
|
|
Error status is currently lost.
|
|
Xapian exceptions seem to handled OK, at least for this case.
|
|
Existing error handling seems adequate, if not ideal.
|
|
At least this Xapian exception is caught. Make sure it stays that way.
|
|
The error message and name were confusing when called in some "read
only" context.
|
|
The current error message is a bit confusing; fix in next commit.
|
|
The API docs promise to handle relative filenames, but the code did
not do it.
Also check for files outside the mail root, as implied by the API
description.
This fixes the bug reported at
id:87sgdqo0rz.fsf@tethera.net
|
|
The current code seems to look for the path relative to the current
working directory, rather than the mail store root.
|
|
Current exception handling seems OK, at least for this case.
|
|
At least this exception is already handled correctly.
|
|
This function only accesses data cached by notmuch, so being closed is
not a problem.
|
|
Xapian currently succeeds to begin/end a transaction on a closed database,
or at least does not throw an exception. Make the test robust against
this changing.
|
|
The logic is that if it's acceptable to return SUCCESS for read only
database, it's acceptable for a closed one.
|
|
Also clarify documentation of error return from n_d_needs_upgrade.
|
|
It's a bit arbitrary which value to return for errors, but the same
argument as for read only databases applies for errors.
|
|
Either an open or closed database should be ok to destroy
|
|
This does not currently throw an error, and it should stay that way.
|
|
notmuch_database_get_version previously returned 0 on some errors, but
did not document this. Luckily 0 is not a valid database version.
|
|
This should not crash, but it does currently.
|
|
These do not crash on a closed database, and we want to keep it that
way.
Start a new file of tests as T560-lib-error was starting to get unwieldy.
|
|
The original generic handler had an extra '%s' in the format
string. Update tests that failed to catch this because the template to
print status strings checked 'stat', which was not set.
|
|
Prevent test suite churn when reported line numbers change.
|
|
Also update the documentation for the behaviour of n_m_get_thread_id
that this fix relies on.
|
|
This is another case where the code should not call INTERNAL_ERROR.
|
|
This is actually one of the few potentially useful things you can do
with a message belonging to a closed database, since in principle you
could re-open the database.
|
|
This should be fine because the message belongs to the
database (talloc context wise).
|
|
Neither of these accesses the database, so should be safe. Add the
tests to catch any changes in exception throwing.
|