🤖 fix: artifact send reports an error for a message it delivered when the turn cannot start
Maintainers usually reply within 1 day
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
- typescript
- Domain
- backend
Research direction
Start by reading src/node/services/artifactInteractions.ts and trace how sendArtifactInteraction handles errors from WorkspaceService.sendMessage. Follow the send route to find where it can distinguish a message that was accepted from a turn that failed to start. Done means the artifact shows no send error after delivery, while the turn error remains in chat and retrying cannot duplicate the message.
Written by the indexing model from the issue text.
Description
Summary
artifacts.sendInteraction returns an error for an artifact message that it already delivered, when the agent turn cannot start. The Artifacts tab then shows the confirm strip with the error and a Send button. Pressing Send delivers the message a second time.
Steps
- Start Xum with no provider API key (or any setup where the turn cannot start).
- Open an artifact with a canvas button (or an HTML page that calls
window.xum.sendfrom a click). - Click the button.
Expected: the "from artifact" message shows in the chat, and the Artifacts tab shows no send error (the message was delivered; the turn error shows in the chat).
Actual: the message shows in the chat (its row is in chat.jsonl), and the strip above the artifact also shows {"type":"api_key_not_found","provider":"anthropic"} with Send and Dismiss. Send delivers a duplicate.
Cause
sendArtifactInteraction (src/node/services/artifactInteractions.ts) treats any Err from WorkspaceService.sendMessage as "not sent" and deletes the pending record. sendMessage can return Err after it appended the user row (turn-start failures such as api_key_not_found).
The bug existed before direct sends: Send in the old strip showed the same error after delivery. Direct sends (the PR that removes the confirm click) make it easier to hit, because a failed clicked send opens the strip.
Fix direction
Tell "accepted, but the turn failed to start" apart from "not accepted" in the send route, and return success for the first one.
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
- Dominant language
- TypeScript
- Stars
- 2.1k
- Forks
- 140
- Avg merge
- 5h 8m
- Merged PRs (30d)
- 952
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from coder/xum
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
Similar issues
-
a10y a10y-audit ai-driven-qa claude
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
linagora/twake-directory-manager#219 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
Maintainers usually reply within 1 day
-
0️⃣ phase/new
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Pulse v7: buildPreferencesFromTelos() bypasses telosSectionOrFile(), renders empty on unified-TELOS installsPossibly taken @zephyr91 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
danielmiessler/LifeOS#2393 ·
Maintainers usually reply within 4 days