Skip to content
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

User status not resetting correctly after a call #31532

Closed
6 of 8 tasks
nickvergessen opened this issue Mar 11, 2022 · 4 comments · Fixed by #31539
Closed
6 of 8 tasks

User status not resetting correctly after a call #31532

nickvergessen opened this issue Mar 11, 2022 · 4 comments · Fixed by #31539

Comments

@nickvergessen
Copy link
Member

⚠️ This issue respects the following points: ⚠️

  • This is a bug, not a question or a configuration/webserver/proxy issue.
  • This issue is not already reported on Github (I've searched it).
  • Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
  • I agree to follow Nextcloud's Code of Conduct.

Bug description

Could be related to #31192 but not really sure. The way the deletion works seems unchanged.

When the bug happens, there are 2 status set for the user:

User MessageId Status IsBackup
_admin null online 1
admin call online 0

The problem is that on the call row the status is already "Online" and not away" as expected, which is why the deletion in

$deleted = $this->mapper->deleteCurrentStatusToRestoreBackup($userId, $messageId ?? '', $status);

doesn't work anymore.
But this was also the case before #31192
if ($userStatus->getMessageId() !== $messageId || $userStatus->getStatus() !== $status) {
// Another status is set automatically, do nothing
return;
}

The question is why the status is not away but online already. Any ideas when this would be updated?

Steps to reproduce

  1. Start a call in talk
  2. See your status being set to "Away + In a call"
  3. Leave the call
  4. See your status is "Online + In a call"

Expected behavior

Status is reset back to "Online"

Installation method

Manual installation

Operating system

Debian/Ubuntu

PHP engine version

PHP 7.4

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 22.2.3 to 22.2.4)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other

Configuration report

No response

List of activated Apps

N/A

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

@nickvergessen nickvergessen added bug 0. Needs triage Pending check for reproducibility or if it fits our roadmap feature: status 1. to develop Accepted and waiting to be taken care of regression and removed 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Mar 11, 2022
@nickvergessen nickvergessen added this to the Nextcloud 23.0.3 milestone Mar 11, 2022
@nickvergessen
Copy link
Member Author

Some more debugging seems to reveal, even while being in a call, the status is already:

User MessageId Status IsBackup
_admin null online 1
admin call online 0

@nickvergessen
Copy link
Member Author

The update seems to come from the heartbeat. If I keep the call open for some time and then toggle between tabs it will update to "online" at some point

@nickvergessen
Copy link
Member Author

The online which comes from the event is more important than the "away" from the in call status:

// If the emitted status is more important than the current status
// treat it as outdated and update
if (array_search($event->getStatus(), StatusService::PRIORITY_ORDERED_STATUSES) < array_search($userStatus->getStatus(), StatusService::PRIORITY_ORDERED_STATUSES)) {
$needsUpdate = true;
}

Potential fix would be to check the messageId in the UserLiveStatusListener as well.
Main question is why this starts happening now as the code in that file didn't change recently.

@nickvergessen
Copy link
Member Author

Found it

$userStatus->setIsUserDefined(false);

this was isUserDefined true

$this->service->setStatus($userId, $status, null, true);

I combined it to false as I followed

$userStatus->setIsUserDefined(false);

but well the status exists because the line before created it:

$this->service->setStatus($userId, $status, null, true);
$this->service->setPredefinedMessage($userId, $messageId, null);

And therefor

// If the status is user-defined and one of the persistent statuses, we
// will not override it.
if ($userStatus->getIsUserDefined() &&
\in_array($userStatus->getStatus(), StatusService::PERSISTENT_STATUSES, true)) {
return;
}

does not exit anymore

puh, that was a bit....

@nickvergessen nickvergessen self-assigned this Mar 11, 2022
@nickvergessen nickvergessen added 3. to review Waiting for reviews and removed 1. to develop Accepted and waiting to be taken care of labels Mar 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant