[bug] Editing a status can result in unexpected changes to content type

[ewwwin]

Describe the bug with a clear and concise description of what the bug is.

/api/v1/statuses/:id/source does not report a status's current content_type. This means that when a user tells a client to edit a post, the client has no information about what the original content type was, and submitting an edit sometimes results in unexpected changes.

If a client sends no content_type back when editing a message, GtS will use the user's "default post format" preference as the new content type for the post. If the post's format was originally something else, it will be changed when the user didn't expect it to be. The client could instead send an explicit content_type with the edit to ensure that the format isn't changed, except that it isn't told what the correct format is, so the bug will manifest no matter what clients try to do.

The only workaround is for users to manually confirm the correct content type is selected every time they edit a post, which is annoying and easy to forget.

What's your GoToSocial Version?

v0.18.0

GoToSocial Arch

amd64 Docker

What happened?

User-level: I edited a markdown post with Enafore, and in the compose popup, the selected content type defaulted to plain text rather than markdown.

API-level: Client fetched /api/v1/statuses/:id/source on the post and received no content_type in the response. (Enafore assumes text/plain in the absence of the field.)

What you expected to happen?

User-level: The selected content type should default to the content type that was used when I initially posted the status (in this case, markdown).

API-level: Client should have received "content_type": "text/markdown" as part of the response.

How to reproduce it?

Make a Markdown post however you like, then request its source:

$ curl -H "Authorization: Bearer $token" "https://my.instance/api/v1/statuses/01JMRB1FB8G01G0W0543DFM7FV/source

{"id":"01JMRB1FB8G01G0W0543DFM7FV","text":"a","spoiler_text":""}

Note the lack of content_type field in the response.

Anything else we need to know?

GtS doesn't currently store a post's content type in the database; in internal/api/model/status.go, it's part of StatusCreateRequest and StatusEditRequest, but not Status or StatusEdit. It should store this on the status, and the stored value should be used as the default content_type for edit requests instead of the user preference (which should only apply to newly-created posts).

Prior art: Glitch stores content_type on statuses in the database and includes it in responses to /api/v1/statuses/:id/source.¹ It also stores it on status edits, which seems to make sense, since content type can be changed by editing, and the point of a StatusEdit is to record such changes. However I'm not sure whether anything actually relies on it being present on edits in practice.

I don't know how this is handled by other servers, though Enafore appears to have some Akkoma-specific logic to check a different field entirely for this information.

In summary:

• Content type should be stored on statuses (and potentially status edits).
• /api/v1/statuses/:id/source should return the content_type of the status.
• When PUT /api/v1/statuses/:id doesn't receive a new content_type, the status's current format should be assumed instead of the "default post format" preference.

Footnotes

1. I'm pretty sure the response to the /statuses/:id/source request is generated by Statuses::SourcesController, which invokes StatusSourceSerializer, which includes the status's content_type from the Status model. ↩

[tsmethurst]

Agreed! Good one, thanks for the details :)