Editing a post with media_ids blanks the id and type of its attachments

Open
  • Is something wrong?
#3,064 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
66/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
php
Domain
api, backend

Research direction

Start in PostService around line 473, where the edit path stores DocumentService::mediaAttachmentsForEdit() via Stream::setAttachments(). Compare with StatusAssemblyService, which uses Stream::setMedias() on create, and with StreamMedia::updateAttachmentInList(). Reproduce the six steps in the issue. Done when an edit returns id 103 and type image, and a second edit naming those ids is accepted.

Written by the indexing model from the issue text.

Description

backend bug

Describe the bug

Editing a post with media_ids (PUT /api/v1/statuses/{id}) blanks every attachment it names: the post is then served with "id": "" and "type": "unknown" for each of them, in the edit's own answer and on every read after it. A later edit that names the ids the post now shows is refused (422 Invalid media attachment list), so a client that edits a post twice cannot keep its media. Naming the original ids again is accepted, but the attachments stay blank.

To Reproduce

On main at 757514521 (0.26.280), as alice, with a direct post so nothing reaches a timeline:

  1. POST /api/v2/media with a PNG: {"id": "103", "type": "image", ...}.
  2. POST /api/v1/statuses with {"status": "probe", "media_ids": ["103"], "visibility": "direct"}: the post has media_attachments: [{"id": "103", "type": "image", ...}].
  3. PUT /api/v1/statuses/{id} with {"status": "probe edited", "media_ids": ["103"]}: 200, media_attachments: [{"id": "", "type": "unknown", ...}].
  4. GET /api/v1/statuses/{id}: the same, "id": "", "type": "unknown".
  5. PUT /api/v1/statuses/{id} with {"status": "probe edited twice", "media_ids": [""]} (the ids step 4 shows): 422 {"error": "Invalid media attachment list"}.
  6. PUT /api/v1/statuses/{id} with "media_ids": ["103"] again: 200, still "id": "", "type": "unknown".

The same happens with form-encoded media_ids[], first seen on 0.26.279.

Expected behavior

The edited post carries the attachments as a new post does: "id": "103", "type": "image", with their previews and alt text, so the next edit can name them.

Cause, as far as I can tell

On create, StatusAssemblyService hands the documents to Stream::setMedias(). On edit, PostService (around line 473) stores DocumentService::mediaAttachmentsForEdit() with Stream::setAttachments(), and that method builds each attachment with convertToMediaAttachment($this->urlGenerator, ACore::FORMAT_ACTIVITYPUB), so the stored list is the ActivityPub shape: no local id, no Mastodon type. StreamMedia::updateAttachmentInList() documents an earlier bug of this kind ("written out again in the ActivityPub shape, without ids, previews or alt text") and stores convertToMediaAttachment($this->urlGenerator)->asLocal() instead; doing the same here, or going through setMedias() as create does, looks like the fix.

Client details:

  • OS: Windows 11, requests sent with Python's urllib (the same as the Aloha Social Android app sends)
  • Browser: none
  • Version: n/a
  • Device: desktop
Server details

Social app version: 0.26.280, main at 757514521

Operating system: Debian (nextcloud-docker-dev)

Web server: Apache 2.4.67

Database: MariaDB 10.6.25

PHP version: 8.5.7

Nextcloud version: 36.0.0 dev

Logs
Nextcloud log (data/nextcloud.log)
Nothing above debug level for these requests.
Browser log
n/a: API requests only.
Dominant language
PHP
Stars
499
Forks
59
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.