Add optimistic UI to a Server Action mutation without letting the UI lie on failure

You are adding optimistic UI to a specific mutation that already runs through a Server Action, using useOptimistic to show the result before the server has actually confirmed it — and you are defining, explicitly, what happens to that optimistic state if the mutation fails, rather than leaving the failure path unhandled.

MUTATION
Adds a comment to a task and should appear in the comment list immediately as the user submits it

CURRENT SERVER ACTION
addCommentAction(taskId, formData), which validates the comment text, inserts a row, and returns { comment } on success or { error } on failure

WHY OPTIMISTIC UI IS NEEDED HERE
Comments are posted frequently during active discussions, and waiting even a second for each one to appear makes the thread feel unresponsive compared to how instant it feels elsewhere in the app

FAILURE BEHAVIOR
The optimistic comment should disappear from the list and a small inline message should say 'Failed to post — try again' next to where the comment box is, with the typed text restored into the box

BUILD RULES
Confirm first that this mutation actually warrants useOptimistic before building anything: the interface has to render a visible result — a new item appearing in a list, a count changing, a toggled state flipping — before the server has confirmed the mutation succeeded, for the added complexity to earn its place; if the UI would be showing a pending spinner either way and nothing changes about what's rendered once the optimistic value lands, useOptimistic isn't buying anything here and a plain pending state is the correct, simpler choice. When constructing the optimistic value inside the updater function passed to useOptimistic, give it a genuine temporary identity — a locally generated id, clearly distinguishable from a real server-assigned one, such as a prefixed string or a negative placeholder number — so the optimistic item can be found and reconciled or removed later without accidentally colliding with a real id a concurrent request might assign. Reconcile the optimistic state with the actual server response the moment the Server Action resolves successfully: replace the temporary item with the real one returned by the action, including its real id and any server-computed fields the optimistic guess couldn't have known, rather than leaving the temporary version rendered indefinitely alongside or instead of the confirmed one. Define the failure path explicitly and make it visible to the user, not silent: when the Server Action's returned state indicates failure, the optimistic value must be rolled back — removed from the list, or reverted to its prior value — and the user needs a clear, specific signal that their action didn't actually take effect, not just a state that quietly reverts with no explanation, which reads as a bug rather than a handled failure. Keep the optimistic update itself free of business logic the server is responsible for — don't have the client-side optimistic guess attempt to validate the input or compute a value only the server can correctly determine, such as a price that depends on tax rules; the optimistic value should be the client's best guess at what the confirmed result will look like, not a parallel reimplementation of server logic that can disagree with the real computation.

OUTPUT FORMAT
The Server Action's return type, the component using useOptimistic including the updater function, and one paragraph specifically describing what a user sees, step by step, if the mutation fails after the optimistic value has already rendered.