Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This addresses Issue #162; the update from sqlcipher-wheel, in Issue #144 also appears to fix the issue with
sigexport
working with Python3.13 and later. That change in requirements.lock also appears here.With a recent update of Signal.app (version 7.44 on iOS, 7.41 on Linux desktop), a
Null
type record appears, which seems to hold message send/receive/edit histories. This causes aKeyError
exception at line 78 of data.py (line 80 in this pull request - I tagged it for easy navigation for myself; feel free to change as you see fit).Uncommenting
data.py: 72
allows interactive inspection just before theKeyError
exception occurs, using Ipython.You can
%load
the following example script to identify theNull
records, which are missing aconversationId
key:In my particular test environment, these are the resulting outputs:
The majority of the records are of type
None
, without aconversationId
key, but they do appear to be tracking message send/recieve/edit actions, and all seem to have asendStateByConversationId
key. This may be useful for further, future logging of these records, if desired.In my debugging, I toyed with using python
try/except
blocks for theKeyError
, as it could be a more general handling. These records may be assigned a "type" in the future, and handling of these kinds of errors could be more generally put in a few statements, or possibly a centralized function. Maybe for a future change.