fix(v0.24): link uploads with PATCH, and stop hiding link failures - #13
Merged
Conversation
Attaching an upload to a memo on a v0.24 server used POST, but the proto binds
SetMemoResources to `patch: "/api/v1/{name=memos/*}/resources"`. Real v0.24.0 and
v0.24.3 both answer 501 Method Not Allowed to the POST. The upload itself had
already succeeded, so the file sat on the server as an unused resource, attached
to nothing and visible on no client — the memo posted fine, just without its
images. v0.25+ was never affected; it uses the attachments endpoint, which the
app already patches.
This was invisible for as long as it was because images used to be embedded in
the markdown content as well, which rendered them even when the link call failed.
Removing that embed in c463cd2 (issue #5) took the cover away and left the plain
bug — on v0.24 only.
The link failure was also caught and logged and nothing else, so a save that lost
its attachments looked exactly like one that worked. It now surfaces the error and
keeps the editor open. The memo itself is already created at that point, so
memoId is captured from the create: retrying updates that memo rather than posting
a duplicate.
Verified end-to-end from the app against memos 0.24.3 and 0.25.3: memo posted with
an image, attachment linked server-side, no unused resources left behind. The
Retrofit-level test pins both verbs — it fails on the old POST.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RZ9mXqLfk6PKwo8V9pVDEC
whtis
force-pushed
the
fix/v024-attachment-link
branch
from
July 19, 2026 11:37
efe0c45 to
5daac7a
Compare
whtis
added a commit
that referenced
this pull request
Jul 19, 2026
Ships the v0.24 attachment-linking fix from #13. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RZ9mXqLfk6PKwo8V9pVDEC
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
Posting a memo with an image against a Memos v0.24 server left the image
invisible everywhere — in the app, on the web client, and in the memo itself.
Server-side the file showed up as an unused resource.
Root cause: linking an upload to a memo went out as
POST, but v0.24's protobinds
SetMemoResourcestopatch: "/api/v1/{name=memos/*}/resources".Probed against real servers:
POSTPATCHThe upload itself always succeeded, so the file landed on the server attached to
nothing. v0.25+ was never affected — it uses the attachments endpoint, which
the app already
PATCHes.Why it stayed hidden
Images used to be embedded in the markdown content as well, which rendered them
even when the link call failed. c463cd2 removed that embed to fix the
double-render on web (#5) — correctly — and in doing so took the cover off this
bug, on v0.24 only.
Changes
MemoApi.setMemoResources:@POST→@PATCH.catchlogged and moved on, so a savethat lost its attachments looked identical to one that worked — that silence is
what let this ship. It now surfaces an error and keeps the editor open. The memo
is already created by that point, so
memoIdis captured from the create:retrying updates that memo instead of posting a duplicate.
endpoints. Negative-tested: reverting to
POSTturns it red.Verification
End-to-end from the app on an emulator against real servers — posted a memo with
an image, then checked the server:
Local
testDebugUnitTest+lintDebuggreen.🤖 Generated with Claude Code
https://claude.ai/code/session_01RZ9mXqLfk6PKwo8V9pVDEC