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

event properties in API responses and AS API duplicated as top-level field #7925

Open
joepie91 opened this issue Jul 21, 2020 · 11 comments
Open
Labels
A-Spec-Compliance places where synapse does not conform to the spec O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.

Comments

@joepie91
Copy link

joepie91 commented Jul 21, 2020

When calling the /messages endpoint (also /search, /context, etc) each event in the chunk will have a number of top-level properties that duplicate those within unsigned:

These top-level properties are not a part of the spec.

(Edited by @richvdh to make the list of affected properties clear)

@clokep clokep added the A-Spec-Compliance places where synapse does not conform to the spec label Jul 21, 2020
@joepie91

This comment was marked as resolved.

@clokep

This comment was marked as resolved.

@richvdh

This comment was marked as resolved.

@joepie91

This comment was marked as resolved.

@richvdh

This comment was marked as resolved.

@joepie91

This comment was marked as resolved.

@richvdh richvdh changed the title age field in /messages duplicated as top-level field event properties /messages duplicated as top-level field Sep 24, 2021
@richvdh richvdh changed the title event properties /messages duplicated as top-level field event properties in /messages response duplicated as top-level field Sep 24, 2021
@richvdh
Copy link
Member

richvdh commented Sep 24, 2021

as long as clients aren't depending on them.

well, therein lies the rub.

Thinking about this a bit harder: any client that wants to use these properties, and be compatible with /sync, must be using the values from unsigned rather than the top-level properties... so I'd be reasonably confident removing them from the top level.

@richvdh
Copy link
Member

richvdh commented Sep 24, 2021

For anyone thinking of looking at this: the code that does the copying is at https://github.com/matrix-org/synapse/blob/v1.43.0/synapse/events/utils.py#L255-L265. Note that that code also includes prev_content which is a slightly more complex case (see matrix-org/matrix-spec-proposals#877). I'd also be inclined to get rid of the unspecced user_id property.

@richvdh richvdh changed the title event properties in /messages response duplicated as top-level field event properties in API responses and AS API duplicated as top-level field Sep 24, 2021
@richvdh
Copy link
Member

richvdh commented Sep 24, 2021

any client that wants to use these properties, and be compatible with /sync, must be using the values from unsigned rather than the top-level properties... so I'd be reasonably confident removing them from the top level.

ARGH. Of course that neglects application services, which don't need to /sync (and the AS API copies the keys to the top level)

@richvdh
Copy link
Member

richvdh commented Sep 24, 2021

I still think we should work to get rid of these spurious top-level keys, but it seems like there is potential for breakage. Accordingly it might be best for us to clarify the situation for prev_content first (matrix-org/matrix-spec-proposals#877) so that then we can break everything at once.

@erikjohnston erikjohnston added the T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. label Sep 27, 2021
@richvdh
Copy link
Member

richvdh commented Feb 1, 2022

MSC3442 clarified that prev_content should be returned under unsigned.

It's still possible that some things - most likely ASes which don't need to worry about /sync - will be broken by removal of these properties, but we really should try and clean them up anyway.

@richvdh richvdh added S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience and removed T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. labels Aug 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Spec-Compliance places where synapse does not conform to the spec O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.
Projects
None yet
Development

No branches or pull requests

4 participants