Open jzacsh opened 2 years ago
jzacsh
commented
2 years ago once I've managed to figure out how to hand-fix this particular error I'm really running into (separately - perhaps I'll try to catch folks in matrix chat) I'll come back here and try to propose a generic solution (eg once I've dug through the importer logic, I'm sure proposal no.1 above will be the fastest)
jzacsh
commented
2 years ago Huh, interestingly on the point of feedback (B) above -- giving user a way to recover -- I don't see a way yet, even though I've identified the bad data.
Here's what I've done;
grepd the file for the text shown in etesync's pim... web ui --> found it on line 4300 --> identified the contact the data belongs toexpected: step 5 should've had bad contact ("Marco") to show up actual: no matches... so either:
jzacsh
commented
2 years ago mini-update: -D flag, per etesync-dav readme luckily means I can easily use my existing install - via systemctl that: systemctl --full --user edit etesync-dav.service (and then modify the Exec line to have a -D at the end).
I'm able to confirm that the error that the web UI is showing is the exact same parse error causing a "full-stop"[1] on contacts sync.
Note: this doesn't really change anything since I think bullet (b) in my last comment still stands: I ultimately have some broken data that I cannot access as a normal user. Next step I think is to see if I can figure out how to write a query myself into whatever the underlying datastore is, and delete the bad record by hand. (and then later think proper fix - ie bullet (A) in my original report above).
[1]: that is: no items seem to serve out of the collection - the entire request 500s I guess, or maybe just tbsync doesn't handle partial failures? I'm not sure
jzacsh
commented
2 years ago jzacsh
commented
2 years ago I ultimately have some broken data that I cannot access as a normal user.
tl;dr: this^ is no longer true.. on my phone at least
Oh, also! Teeny-tiny success: I figured out Android's default contacts app lets me see the bad record (whereas webapp still doesn't). So I was able to delete it (and without deleting the totally-fine Google contacts copy: tap overflow menu --> tap "view linked contacts" --> tap etesync one --> tap overflow menu --> delete .. this ultimately deletes just etesync's copy)
jzacsh
commented
2 years ago I ultimately have some broken data that I cannot access as a normal user.
tl;dr: this^ is no longer true.. on my phone at least
tl;dr confirmed that^ fix was limited to phone and server databases; laptop's DB still has bad record
So despite my deleting successfully (last comment), tbsync on thunderbird now seems to hit a new and different, but related HTTP 500 where the nature of the error looks the same but .. maybe it's an error about a locally-cached copy somewhere I can't see... like an offline copy of the etebase data?
jzacsh
commented
2 years ago update: I deleted my local data (etesync-dav del myuser && systemctl --user restart etesync-dav.service), setup my user again and reconfigured tbsync, but now I get the same error, just the hash has changed (I'm guessing that's just the re-sync down from pim.etesync.. servers).
So it's probably the same record somehow...
tl;dr confirmed that^ fix was limited to phone and server databases; laptop's DB still has bad record
... despite that^ claim that I succeeded in deleting it :thinking:
tl;dr user-input shouldn't cause crash, it should be reject (or a graceful way out should be offered, if it's not rejected).
warning: I'm not sure where this issue should live - I'm hopping around etesync codebases at this point, so "server" seems like a generic enough home...
feedback/bug report
(All of the "actual" descriptions have a corresponding screenshot/inlined pastie below.)
Two things I think could be better:
pim...webapp) and server logs (like etesync-dav), I can figure out how to locate the bad record (eg a link to an FAQ doc entry like "how to hand-edit the ID corresponding to record to exceptions for/myusername/SOMEHASH")symptoms
Early on when setting up etesync, I believe my import from 6 months ago apparently had some bad record that I must've been allowed to ignore. Lately I've noticed the pim webapp has a little red error icon, though (screenshot below).
Then much later downstream when I'm setting up DAV sync, I eventually hit the same(?) error. I think it's the same - all I have is symptoms to share right now, no proof:
Here's a screenshot of all the errors and a text transcription of what's shown
here's a screenshot where you can see all the information I have to go on; summarizing the screenshot: 1. **middle of screen in `pim` webapp**: _some_ contact imported (months and months ago) from Google Contacts is producing the import error - **feedback**: there's nothing call to action here here. That is: there's no indication of how to find the supposedly bad contact data that triggered this exception. That is: how should one fix this? Find the corresponding etesync data and hand-edit it? Delete all my etesync account data and re-import (I hope not)?, etc. 2. **top of screen in tbsync**: you can see tbsync fails I'm _entirely guessing_ due to the above error - the only other log I have to go on from tbsync is the next bits of info (2.a) and (3)... - **rightside of screen** eventlog from this thunderbird add on says: ``` URL: http://localhost:37358/MYUSER/SOME_OPAQUE_HASH/ (PROPFIND) Request: