fix(actions): surface inner result envelope (no more false-success on failed actions)#69
Merged
Merged
Conversation
…t report success
Object-action / flow / api routes wrap the handler's own result, so a transport
200 with `{ success: true }` can still carry an INNER `{ success: false, error }`
in `data` (e.g. "Action 'x' not found"). dispatchServerAction/dispatchFlow/
dispatchApi only checked the OUTER flag, so a failed action was reported to the
user as success with no error.
Add a shared interpretEnvelope() that unwraps one level and honours the inner
`success`, lifting the inner `error` for display. Use it at all three dispatch
sites. (Same envelope trap useTriggerFlow already handles for flow runs.)
Unit-tested against the real payload; lint + typecheck clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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
2 participants
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.
Problem
Object-action / flow / api routes wrap the handler's own result, so a transport 200 with
{ success: true }can still carry an inner{ success: false, error }indata— e.g.{"success":true,"data":{"success":false,"error":"Action 'clone_opportunity' not found"}}.dispatchServerAction/dispatchFlow/dispatchApionly checked the outer flag, so a failed action was reported to the user as success with no error (flagged during the 7.5 verification).Fix
Add a shared
interpretEnvelope()that unwraps one level and honours the innersuccess, lifting the innererrorfor display; use it at all three dispatch sites. This is the same envelope trapuseTriggerFlowalready handles for flow runs.Verification
interpretEnvelopeunit tests, including the exact production payload (innersuccess:false→ failure with lifted error), outer-failure, non-OK HTTP, and the success/reload cases — 6 pass.eslint+tscclean; full suite 1141 pass (20 pre-existing snapshot failures, unrelated).successpath was already browser-verified last PR (flow-trigger error toast), via the same toast mechanismrunRecordActionuses.Closes the follow-up noted in #63 / #64.
🤖 Generated with Claude Code