Closed 0mp closed 2 years ago
Hmm, so it turns out it is not really a bug in scli. My history file was corrupted. Here's the end of the file:
{
"source": "+123456789",
"sourceName": "XYZ",
"sourceDevice": 1,
"timestamp": 1628935184419,
"syncMessage": {
"sentMessage": {
Once I removed this broken object and closed the "envelopes" array and the outermost object (i.e., ]}
) scli started just fine.
I'm not sure if that's a bug. Sure, scli could suggest the user to look there but I'm not sure if that's a priority.
Cheers!
There are a few commits in master
to address just this kind of problem (ref. https://github.com/isamert/scli/issues/112#issuecomment-927099678), but unfortunately they are not in a point release yet. I'll make a new release once everything is tested with the fresh signal-cli v0.9.1.
EDIT: sorry, missed your second message when writing this comment; so the stuff below you already knew:
Looks like the history file got corrupted :(. Could have been a result of an anomalous termination (e.g. receiving SIGKILL
).
You can try editing the history file manually to make it a valid JSON file - to keep whatever has been saved during scli's last shutdown (the completeness is determined by luck). If you don't mind losing it, you can just delete the history file.
Hi, I think I hit a bug in how scli is parsing the JSON string from signal-cli:
Versions I run:
Please let me know if there is anything I can do to help debugging this issue.
Cheers!