m.room.retention doesn't work on all rooms

[elixx]

Description

I set the m.room.retention state event on a number of rooms.
The retention policy appears to work on traditionally created rooms (i.e. via Element "Add new room"), but rooms created by a direct message accept the state event but old messages do not get purged.
From what I can tell, direct-message rooms have a room ID and properties just like the other rooms, and it accepted the state event, so I expected this to work.

Steps to reproduce

• Configure synapse with retention policy (retention: enabled: true, defaults, and purge jobs). My settings are included at the bottom of thispost.
• Send message from user A to user B to start a direct message.
• In Element's Room Settings / Devtools, send a state event type m.room.retention to set max_lifetime on the room.

I've done this on other standard rooms, and the results stick and appear the same when viewing the room state after sending. I checked that both the working rooms and the non-working rooms show up as room version 6.

Version information

• Homeserver:
  locally hosted docker container

• Version:
  current master
server_version: "1.21.2"
python_version: "3.7.9"

• Install method:
  matrixdotorg/synapse image via docker-compose build

• Platform:
  Docker on Ubuntu

retention:
  enabled: true
  default_policy:
    min_lifetime: 7d
    max_lifetime: 30d
  allowed_lifetime_min: 1h
  allowed_lifetime_max: 10y
  purge_jobs:
    - longest_max_lifetime: 2d
      interval: 1h
    - shortest_max_lifetime: 2d
      interval: 12h

[anoadragon453]

Direct Message rooms in Element are created as encrypted rooms by default, which I imagine is probably the differentiating factor here.

Regular events in encrypted rooms are encrypted and obfuscated so the server cannot read them, but state events are not. This allows retention information to be read by the server even in encrypted rooms.

Synapse v1.21.2 has a bug in that retention information is accepted from regular events as well as state events. The fix is due to land in the next release cycle: #8527

Is it possible that you've been sending your retention events as regular events rather than a state event? This would mean they would get read and apply in unencrypted rooms (most public rooms), but not apply in DMs (usually encrypted).

You can check by looking at /devtools -> Explore room state -> look for an m.room.retention entry in an afflicted DM room. Alternatively, make sure the event structure has a state_key field.

[elixx]

The retention policy is working as expected on both encrypted and non-encrypted normal rooms.
When I was getting the policies set up and working on the normal rooms, I made the mistake of sending a regular event instead of a state event. I'm definitely using the same parameters for the state event in the "DM" room.

Both the message room and some of the working rooms show up as Room Version 6 and have encryption enabled.

Non-working state:

Compared to a traditional room with working retention setting:

[anoadragon453]

I notice that the type in your first example contains an extra space at the end, which may break things.

[elixx]

Thanks, good catch. I feel silly if that was it, the whole time.
I will test and report back / close once confirmed.

Pretty sure that will do it. After I sent the initial state, I was just clicking to edit the original state that was created (obv. sufficed with the space).

[elixx]

It has already worked. Thanks again.