jetpack
jetpack copied to clipboard
Jetpack connection error banner requires account re-log in
Impacted plugin
Jetpack
Quick summary
I've seen multiple cases where users need to log out and log back in to get rid of the Jetpack connection error banner at the top of their dashboard.
Steps to reproduce
I was able to replicate it only once after running a Migrate Guru import, but I'm not sure if importers are the only pattern.
A clear and concise description of what you expected to happen.
To not see the banner
What actually happened
The banner was there despite Jetpack connection being fine until they logged out and logged back again into their accounts.
Impact
Some (< 50%)
Available workarounds?
No but the platform is still usable
Platform (Simple and/or Atomic)
Atomic
Logs or notes
7819657-zen
Support References
This comment is automatically generated. Please do not edit it.
- [ ] 7819657-zen
- [ ] 7838662-zen
- [ ] 7827116-zen
- [ ] 7843629-zen
- [ ] 7843053-zen
- [ ] 7837741-zen
- [ ] 7844298-zen
- [ ] 7817607-zen
- [ ] 7821209-zen
- [ ] 7832319-zen
- [ ] 7817794-zen
- [ ] 7853472-zen
- [ ] 7854937-zen
- [ ] 7857128-zen
- [ ] 7861034-zen
- [ ] 7609980-zen
- [ ] 7883214-zen
- [ ] 7894752-zen
- [ ] 7899189-zen
- [ ] 7915998-zen
- [ ] 8092476-zen
- [ ] 8141815-zen
Reported in 7838662-zen
Resolved after log out → clear cache → log in cycle.
I've seen multiple cases where users need to log out and log back in to get rid of the Jetpack connection error banner at the top of their dashboard.
Could you tell us more? Is this happening only on Atomic? What does the connection error banner look like, what does it say? When you say "log out and log back in", do you mean logging out of WordPress.com, or just out of the site itself somehow (if that's possible with the masterbar)?
Thank you!
I suspect that 7827116-zen might be one of these cases.
7843629-zen 7843053-zen
Another report: 7837741-zen
7844298-zen
@jeherve In short, yes. Everything looks good and there are no errors apart from that banner. Another case:
LE: The message in English:
I'm trying to find an example in English too, but I believe that goes along the lines of "there's an issue communicating with Jetpack" or so.
Thank you! And this goes away from logging out of WordPress.com and logging back in?
This may be worth moving to the Calypso repo, since it happens in that environment and may have to be fixed there.
Examples of this issue I've run into this week are listed below.
I have a predef that asks folks to 1 logout/in, 2 clear cache, and then 3 clear network cache, so I don't always know which step solves the issue; but I'll note below if the user tells us which step resolved it:
- 7817607-zen (solution: Logging out/in)
- 7821209-zen
- 7832319-zen (solution: browser cache)
- 7817794-zen
- 7853472-zen
7854937-zen
@jeherve
And this goes away from logging out of WordPress.com and logging back in?
Yes.
This may be worth moving to the Calypso repo, since it happens in that environment and may have to be fixed there.
Sure! Who do we ping about it?
7857128-zen
@Automattic/yolo Since you worked on https://github.com/Automattic/wp-calypso/pull/80429 , I was wondering if this rang a bell for y'all. I'm not able to reproduce on my test Atomic sites right now, so it makes it hard to understand what's getting in the way here.
7861034-zen
Potentially another case in 7609980-zen - I asked them to try logging out and in.
I was wondering if this rang a bell for y'all. I'm not able to reproduce on my test Atomic sites right now, so it makes it hard to understand what's getting in the way here.
@jeherve I have those potential steps in mind:
- User's site has Jetpack connection problems caused, for example, by DNS change or migration
- Banner is displayed in Calypso
- The user fixes the problem
- Calypso doesn't validate the connection again, so the banner is still displayed
- The user logs out and logs again, what triggers the validation, and banner gets hidden
We will check this.
Thank you! It does make sense that way.
7883214-zen
7894752-zen
7899189-zen
7915998-zen
- I deployed a fix that prevents the error banner from being stuck https://github.com/Automattic/wp-calypso/pull/88698 After fixing a Jetpack connection, the user will need to wait around 2 mins to see the banner hidden after any interaction.
I'm closing this issue now, but feel free to reopen it if new users experience it again. The main bug was fixed, but there may be other edge cases.
Thanks for fixing it @sejas !
looks like we might have a new report here: 8092476-zen.
looks like we might have a new report here: 8092476-zen.
@tvolpert , thanks for reporting, I tried user's site and it worked fine on my side.
I think we have another instance here: 8141815-zen
@sejas a big part of the problem with this issue is, in most cases, we haven't been able to replicate it on the user's site when SU'd, even as they report it persisting on their end.
In both of these last two cases I've advised the user to try logging out and back in, which of course disconnects them from chat -- but I'm assuming it fixed the issue or we would have heard from them again
Thanks for commenting. Currently if a user see the message can be cause by two reasons:
- There is a real issue and the message will persist until they fix it.
- There was a temporal error (DNS, network ...) and after two minutes if they refresh the page or click in almost anywhere, like hosting config, we will refetch the current status and hide the message if the error is gone.
I wonder if we should add a button to re-trigger the check manually.
@tvolpert, Do you think that would help users?