-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error: No record for device +xx690.2 (shortly after PUT v1/messages/+xx690 409 Error) #2762
Comments
That is some high-quality debugging. Many thanks to you. I too suspect that 'deleting session' line. One thing you can do to be sure about that is have that user '...690' user send message to you from each of their devices in turn, and you can then determine, from the logs, which device is which number. |
Okay, from successful encrypted-call a few minutes ago (between my signal4android and their signal4smartphone device xx690.1), they did NOT ever end up getting their third device to have a linked copy of signal4desktop, so I've corrected my submission above. The current understanding is therefore that
so the HTTP 409 error in my debuglogs was their (single) install of signal4desktop "disappearing" somehow, as far as my own signal4desktop installation is concerned. They have a windows laptop, but did not know the OS version or anything. I'm going to try and get more info from them later, but they are extremely busy and a V.I.P. type in our groupchat so I'm hoping we can debug without bothering them too much. :-) Is there a significant risk that the 409 problem is on THEIR end rather than my end, i.e. they unlinked their device somehow, rather than specific to my end? Should I contact other people in the mutual groupchat, to see whether they got the messages to come through properly? In particular, note that one of the other people in the groupchat is xx165.2, who also has a signal4smartphone and a signal4laptop installation, also has a 409 error in my debuglogs (happened a few seconds after the xx690.2 received a 409 error), so presumably the next time my xx165.2 contact sends me a message via their laptop it will also fail. This is why my running assumption is that the problem is on my end... two problems manifested with two different contacts simultaneously would usually indicate my system is at fault... or perhaps, it might not be me, maybe the root cause is that they both got auto-updated signal4windows pushes simultaneously which busted them for all recipients, not just for myself? |
409 is generally about the server telling the requesting client that it has out-of-date information. You are required to send to every device that a given account owns when you send to them, and you have to have updated information for each to prove that you have a chance of communicating with them successfully. So the problem here is likely desktop's book-keeping before or after that call, but there is an outside chance that the server is responding with a 409 when it shouldn't. |
I have not been successful in getting my remote contact to provide the debuglogs from their end, and my assumption is that this means we won't be able to track down the root cause. Closing this for now. If somebody runs into the same problem, please re-open (and @five-c-d please also) |
Bug description
I successfully received a direct 2-way message from my contact xx690 yesterday -- they are using one phone plus
twocorrection: one linked devices. I am using one phone plus one linked device, and both my devices received the message. According to the debuglog from my linked device, this message was sent from xx690.1 which must be their signal4smartphoneAround seven hours later, my contact sent a series of additional messages, one to me directly, and several to a groupchat we are both members of, which according to my logfiles were from xx690.2 this time around. All these messages were received properly on my signal4android device, but none of them were received properly on my signal4desktop device. First of all, the attemptd-messages were ALL shown in the 2-way conversation (rather than one in our 2-way conversation and the rest in the groupchat conversation). Every message surfaced the same error -- "Error handling incoming message" and when viewing MoreInfo this was expanded to also say "Error No record for device +1xx690.2" which must be their windows laptop
Although it is not guaranteed to be the cause of the problem explained above, I am highly suspicious of this entry in the debuglog, which occurred prior to the happenings above:
Steps to reproduce
install signal4desktop as xx690.1, install another copy of signal4desktop as xx690.2, link them allActual result:
Out of the blue, you begin seeing the errors above. In addition to several textual-content-only messages, a couple of the most recent attempted-messages the contact attempted to send a pdf ~375kb to groupchat, and a docfile ~36kb in the 2-way conversation, which HAS been done before (successfully).
Expected result:
Lack of the 'HTTP 409 Error' preferably, and especially lack of the 'Error No record for device', i.e. messaging continues successfully on all linked devices (not just signal4android)
Screenshots
(Not needed... standard grey bubbles containing 'Error handling incoming message' italicized plus timestamp as well as with red-circle-around-red-exclamation-mark on the signal4desktop instance, and the corresponding standard grey bubbles with no red-icon and no errors on signal4android.)
Platform info
Signal version: v1.15.5-beta.1
Operating System: Arch Linux 4.17
Linked device version: 4.25.10 when this error happened , but in the process of preparing the debuglogs it has auto-upgraded itself to 4.26.2 as of a short time ago
Link to debug log
signal4desktop == https://debuglogs.org/b63e560f345cb2312ac85c1f25ad5fe4b56830dc1e118c09573eca81d72fe59d
signal4android == https://debuglogs.org/e64060ee9bdf03ab9a4ad5c729433a383ccf815e0e2383eb783db8af8994c238
Searching turned up the following
Probably not related == Long delay time between sent messages #1088 , HTTP 409 thanks to local firewall-rules and (pre-electron) use of port 4433 , fixed by electron using standard https port 443 nowadays
Could be related == No record for device #1341 , No record for device + Error handling incoming message + messages okay on signal4android , closed as needing-new-debuglogs-from-signal4desktop-electron-not-chromeApp [might need to reopen? no 409 though]
Could be related == "Error handling incoming messages" for all freshley imported msgs in electron App #1628 , "Error handling incoming messages" for all freshley imported msgs in electron App + HTTP 409 + Error Bad MAC
Probably not related == Receiving messages not meant for me while updating desktop version #1673 , HTTP 409 thanks to key problems caused by inadvertently copying another enduser's ~/.config/Signal into their own system by mistake , fixed by not doing that :-)
Vaguely related == Changed contact name on iOS produces "Error handling incoming message" on Desktop #2052 , Changed contact name on iOS produces "Error handling incoming message" on Desktop + queueCached error handling item + Error: No record for device +[REDACTED]633.1
Could be related == "Error handling incoming message", "No record for device" on Windows client #2055 , "Error handling incoming message", "No record for device" on Windows client + sender of message recently upgraded their signal4windows to a later version [not sure if my contact received an auto-updated version of signal4desktop yesterday sometime?]
Probably not related == Unable to send messages due to not being able to retrieve private keys because rate limiting. #2180 , HTTP 409 conflict which was always immediately followed by HTTP 413 rate-limiting , fixed by rebooting&resetting
Maybe related == Invalid date #2286 , Invalid date + No record for device [phone number].2 ... [OP amichair's debuglog is no longer available (access denied), other people commenting in the thread had different issues]
Vaguely related == "Message encrypted for non-existing session" after failed sync of a stale desktop client #2746 , "Message encrypted for non-existing session" after failed sync of a stale desktop client + No record for device + Failed to fetch prekey + Duplicate PreKeyMessage for session + Top-level unhandled promise rejection: MessageCounterError: Message key not found. The counter was repeated or the key was not filled. + queueDecryptedEnvelope error handling envelope HTTPError: promiseAjax: error response; code: 404
Other background info
I have not closed my signal4desktop instance, nor otherwise interfered with it very much since noticing the error-messages (a couple of messages sent and received in other conversations). Should I do anything else on this end? Reboot? Reset secure session on signal4android which is linked to the signal4desktop instance? Reset secure session via the dev-console somehow? Look for problems somewhere on the filesystem or in the databases perhaps on this end? Upgrade to latest beta version of signal4desktop? I do not have access to the sender's three devices and they will be VERY unlikely to want to mess around with trying to debug this problem with us. That said, I'm happy to do what I can on this end, if there is anything which might help.
I noticed a bunch of HTTP 403 errors in my debuglogs related to three specific profiles... not sure what that is about, should I file a separate github issue?
$ curl --insecure --url https://cdn.signal.org/profiles/iVQqlnFORZ0zQTbWfSwrgg
AccessDenied
Access Denied34215EB5EFB4031F[REDACTED]$ curl --insecure --url https://cdn.signal.org/profiles/tZi6zHefLoFhwsUdtFX2dA
Warning: Binary output [snip...]
Process bug
Over in the righthand sidebar of this github-create-a-new-issue window, there is a little popup which says 'It looks like this is your first time opening an issue in this project! \n Be sure to review the contributing guidelines.' with a link to here == https://github.com/signalapp/Signal-Desktop/blob/development/CONTRIBUTING.md , but that is a helpdoc for people contributing pull-requests rather than for people filing new github-issues. Unless... perhaps that was a not-so-subtle hint? ;-)
The text was updated successfully, but these errors were encountered: