Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

status_msg is overwritten when presence is changed (user goes offline) #2245

Closed
jfrederickson opened this issue May 23, 2017 · 11 comments · Fixed by #10550
Closed

status_msg is overwritten when presence is changed (user goes offline) #2245

jfrederickson opened this issue May 23, 2017 · 11 comments · Fixed by #10550
Labels
A-Presence good first issue Good for newcomers P4 (OBSOLETE: use S- labels.) Okay backlog: will not schedule, will accept patches S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. z-bug (Deprecated Label)

Comments

@jfrederickson
Copy link

I was testing the status and presence features of Matrix, and noticed this:

>>> client.set_status("@sibyl:localhost", "test and stuff")
>>> client.get_status("@sibyl:localhost")
{'user_id': '@sibyl:localhost', 'presence': 'online', 'status_msg': 'test and stuff', 'last_active_ago': 1836, 'currently_active': True}
>>> client.get_status("@sibyl:localhost")
{'user_id': '@sibyl:localhost', 'presence': 'online', 'status_msg': 'test and stuff', 'last_active_ago': 11886, 'currently_active': True}
>>> client.get_status("@sibyl:localhost")
{'user_id': '@sibyl:localhost', 'presence': 'online', 'status_msg': 'test and stuff', 'last_active_ago': 22203, 'currently_active': True}
>>> client.get_status("@sibyl:localhost")
{'user_id': '@sibyl:localhost', 'presence': 'online', 'status_msg': 'test and stuff', 'last_active_ago': 34950, 'currently_active': True}
>>> client.get_status("@sibyl:localhost")
{'user_id': '@sibyl:localhost', 'presence': 'online', 'status_msg': 'test and stuff', 'last_active_ago': 52767, 'currently_active': True}
>>> client.get_status("@sibyl:localhost")
{'user_id': '@sibyl:localhost', 'presence': 'offline', 'last_active_ago': 69343}

My status_msg appears to be overwritten when my status changes to "offline" due to inactivity. Needless to say, this makes status_msg not so useful.

This is using matrix-python-sdk (with my presence changes), and the only active client at the time for that user was the SDK I was using to enter those function calls above.

@ShadowJonathan
Copy link
Contributor

Is this a spec issue? (to specify that status_msg shouldn't be touched if it's key is omitted from a status update)

@deepbluev7
Copy link
Contributor

I wouldn't say so. There is no status update function called client side. It is simply synapse, that marks the client as offline, because it does not call /sync for 5 minutes, which then wipes the status_msg. There is no way for clients to prevent that, apart from never going offline.

@dklimpel
Copy link
Contributor

Is this issue still relevant?
I cannot reproduce.

I have set a status. Logged out. user goes offline. Status is still existent and has not changed.

@deepbluev7
Copy link
Contributor

@dklimpel You probably didn't set a status_msg but an im.vector.status state event. Which is not part of the presence module or even the spec. At least here my status_msg still vanishes regularly, but I last tested it 2 weeks ago.

@dklimpel
Copy link
Contributor

@dklimpel You probably didn't set a status_msg but an im.vector.status state event. Which is not part of the presence module or even the spec. At least here my status_msg still vanishes regularly, but I last tested it 2 weeks ago.

Yes you are right. I did a second check. This is im.vector.status.

@dklimpel
Copy link
Contributor

IMO it is not a spec issue:
https://matrix.org/docs/spec/client_server/latest#last-active-ago
There are no information about reset status_msg whe user is unavailable .

@dklimpel
Copy link
Contributor

I think in this part Synapse sets status_msg to None if user is offline.

if not ignore_status_msg:
msg = status_msg if presence != PresenceState.OFFLINE else None
new_fields["status_msg"] = msg

Introduced in #582 with b31ec21

@erikjohnston
Copy link
Member

It's not clear to me if this is expected behaviour or not, and I think depends on the use case a bit (e.g. how ephemeral is the status message meant to be?)

@deepbluev7
Copy link
Contributor

Imo it is pretty annoying having to manually set the status_msg every morning, but yeah, I guess it depends on the use case. I am fine with not sending it when offline, but having to restore it after going online seems wrong to me.

@callahad callahad added P5 (OBSOLETE: use S- labels.) Dubious backlog: will not schedule, but may consider patches T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. S-Tolerable Minor significance, cosmetic issues, low or no impact to users. P4 (OBSOLETE: use S- labels.) Okay backlog: will not schedule, will accept patches and removed X-Needs-Discussion P5 (OBSOLETE: use S- labels.) Dubious backlog: will not schedule, but may consider patches labels Aug 5, 2021
@callahad
Copy link
Contributor

callahad commented Aug 5, 2021

IMO it is not a spec issue:
https://matrix.org/docs/spec/client_server/latest#last-active-ago
There are no information about reset status_msg whe user is unavailable .

This is compelling: the spec does not require clearing (nor persisting!) the status_msg when state changes, so Synapse's decision to proactively clear the state is arbitrary, and on balance, seems more harmful than allowing it to persist.

Tagging as a bug; patches are welcome.

A patch is likely as simple as removing the if presence != PresenceState.OFFLINE else None clause from:

if not ignore_status_msg:
msg = status_msg if presence != PresenceState.OFFLINE else None
new_fields["status_msg"] = msg

(and adding / adjusting some tests)

@callahad callahad added the good first issue Good for newcomers label Aug 5, 2021
@dklimpel
Copy link
Contributor

dklimpel commented Aug 5, 2021

I will create a PR. It is not only this one line. :(

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Presence good first issue Good for newcomers P4 (OBSOLETE: use S- labels.) Okay backlog: will not schedule, will accept patches S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. z-bug (Deprecated Label)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants