tinyhumansai/openhuman · error · Error
Comment deletion was not accepted by the backend
Error message
Comment deletion was not accepted by the backend
What it means
Thrown in the Agent World feed comment-delete confirm modal (#4197) when apiClient.feeds.deleteComment(handle, postId, comment.commentId) resolves with { ok: false } - the backend received the request but refused the deletion. This is a soft failure (HTTP-level success, application-level refusal), not a network error; both land in the same .catch which only console.errors, so the comment silently stays in the UI.
Source
Thrown at app/src/agentworld/pages/FeedSection.tsx:612
postId,
onCommentDeleted,
}: {
comment: GqlComment;
myAgentId: string | null;
handle: string;
postId: string;
onCommentDeleted: () => void;
}) {
// Drives the in-app confirm modal for comment deletion (#4197).
const [confirmingDelete, setConfirmingDelete] = useState(false);
const [deleting, setDeleting] = useState(false);
const confirmDeleteComment = () => {
setDeleting(true);
void apiClient.feeds
.deleteComment(handle, postId, comment.commentId)
.then(({ ok }) => {
if (!ok) throw new Error('Comment deletion was not accepted by the backend');
onCommentDeleted();
})
.catch(err => console.error('[FeedSection] delete comment failed:', err))
.finally(() => {
setDeleting(false);
setConfirmingDelete(false);
});
};
return (
<div className="flex gap-3 py-3">
{comment.author.avatarUrl ? (
<img
src={comment.author.avatarUrl}
alt={comment.author.displayName}
className="h-7 w-7 shrink-0 rounded-full object-cover"
/>
) : (View on GitHub (pinned to 7491200858)
Solutions
- Refetch the feed (homeFeed) and retry deletion only if the comment still appears - the usual cause is a stale commentId
- Verify the handle/postId/commentId trio matches the rendered comment (not data left over from pagination)
- Inspect the network response body for deleteComment - ok:false is opaque by design, but the payload may carry a reason field
- If it reproduces reliably, extend deleteComment to surface a reason and show a user-visible toast instead of console.error only
Example fix
// before
.then(({ ok }) => {
if (!ok) throw new Error('Comment deletion was not accepted by the backend');
onCommentDeleted();
})
.catch(err => console.error('[FeedSection] delete comment failed:', err));
// after - surface the failure and resync instead of only logging
.then(({ ok }) => {
if (!ok) throw new Error('Comment deletion was not accepted by the backend');
onCommentDeleted();
})
.catch(err => {
console.error('[FeedSection] delete comment failed:', err);
setDeleteError(err instanceof Error ? err.message : String(err)); // banner in the modal
onCommentDeleted(); // reuse the refresh callback to drop stale comments
}); Defensive patterns
Strategy: try-catch
Validate before calling
// Before deleting, confirm the comment is still in the loaded feed state
// (stale ids after deletion elsewhere are the top cause of ok:false).
const stillPresent = feedState.comments.some(c => c.commentId === comment.commentId);
if (!stillPresent) { onCommentDeleted(); return; } // treat as already deleted Try / catch
// keep the .catch but make it user-visible and resync on failure
void apiClient.feeds.deleteComment(handle, postId, comment.commentId)
.then(({ ok }) => {
if (!ok) throw new Error('Comment deletion was not accepted by the backend');
onCommentDeleted();
})
.catch(err => {
console.error('[FeedSection] delete comment failed:', err);
setDeleteError(err instanceof Error ? err.message : String(err));
onCommentDeleted(); // refresh so the UI converges with the backend
}); Prevention
- Treat ok:false as a first-class outcome of every feeds mutation - check it explicitly rather than assuming resolve means success
- Always run a feed refresh after a failed delete so stale rows drop out of the UI
- Never reuse commentId values captured before a pagination/refetch cycle
When it happens
Trigger: User clicks Delete on a comment and confirms, and the feeds backend returns ok:false - e.g. the comment was already deleted from another session/window, the actor's handle lacks delete permission on that feed, or the postId/commentId passed from stale feed state no longer match a live row.
Common situations: Two windows/two devices on the same feed where one already deleted the comment; feed state left stale after a reconnect or account switch (old handle no longer authorized); backend implemented to answer refusals as 200 + ok:false rather than 4xx, so nothing surfaces except the console.
Related errors
AI-assisted analysis of tinyhumansai/openhuman@7491200858 (2026-08-17).
Data as JSON: /api/errors/ac2e7ede529240ca.
Report an issue: GitHub.