`/sync` response's `account_data` includes an `m.push_rules` event which doesn't include required `room.default` attribute

Description

Using a current version matrix-nio on the default matrix.org homeserver I experience the following: https://github.com/poljar/matrix-nio/issues/348

The request: https://matrix.org/_matrix/client/r0/sync?access_token=<snip>&since=s3281165653_757284974_12692804_1597914399_1620552403_3573198_592315752_5209106983_0&full_state=true&timeout=0&filter=%7B%22room%22%3A%7B%22timeline%22%3A%7B%22limit%22%3A30%7D%2C%22state%22%3A%7B%22lazy_load_members%22%3Atrue%7D%7D%7D'

produces the following json:

{
  "next_batch": "s3281181518_757284974_12713739_1597925487_1620566333_3573208_592321297_5209124871_0",
  "account_data": {
    "events": [
      {
        "type": "m.push_rules",
        "content": {
          "global": {
            "room": [
              {
                "actions": [
                  "dont_notify"
                ],
                "rule_id": "!<roomid>:matrix.org",
                "enabled": true
              }
            ],

According to https://matrix.org/docs/api/#get-/_matrix/client/v3/pushrules/ the room.default parameter is required, but is not included in the “room” data.

Steps to reproduce

• After a login request, perform a /sync request like the folling https://matrix.org/_matrix/client/r0/sync?access_token=<snip>&since=s3281165653_757284974_12692804_1597914399_1620552403_3573198_592315752_5209106983_0&full_state=true&timeout=0&filter=%7B%22room%22%3A%7B%22timeline%22%3A%7B%22limit%22%3A30%7D%2C%22state%22%3A%7B%22lazy_load_members%22%3Atrue%7D%7D%7D'
• Note that the “default” parameter is not included in the “room” push_rules

Homeserver

matrix.org

Synapse Version

{“server”:{“name”:“Synapse”,“version”:“1.67.0 (b=matrix-org-hotfixes,3a5edde170)”}}

Installation Method

No response

Platform

n/a

Relevant log output

n/a

Anything else that would be useful to know?

No response

[richvdh]

It would be nicer to have it fixed either in the spec or in synapse, so that we don’t have to carry a patch.

I don’t think this was a deliberate change; it should be fixed in synapse rather than the spec.

[nico-famedly]

This issue breaks our SDK, which uses the openapi spec to generate the pushrule classes (where this is marked as required). This means when using custom push rules, we can’t process push rules properly anymore nor can we properly modify them anymore. While we can work around this by patching the openapi spec before generating our code, this means that some of our deployments are currently experiencing this regression and can’t use their custom pushrules anymore via our clients. It would be nicer to have it fixed either in the spec or in synapse, so that we don’t have to carry a patch.