ATVP client SDK accepts an outcome value the Cases API always rejects
HTTP 400 feedback_outcome_invalid when calling recordDownloadFeedback(intentId, 'non_responsive')
The @querykey-research/atvp-client SDK's FeedbackLoop.recordDownloadFeedback() (and the not-yet-published GitHub Action wrapping it) both listed nonresponsive as a valid caller-supplied outcome, but the Cases API's real outcome-alias map has no such entry - every call using it would pass client-side validation and then fail server-side with feedbackoutcomeinvalid. nonresponsive is a state the server detects automatically on download-intent deadline timeout; it was never meant to be caller-reported.
Root Cause
The SDK's validOutcomes list (['confirm', 'refute', 'nonresponsive']) was written without cross-checking it against the server's actual OUTCOMEALIASES map in atvp-feedback-gateway.js, which only recognizes confirm/confirmed/success/successfulapplication, derive/derived/derivedapplication, refute/refuted/fail/failed/failedapplication, and rollback/rollbackinvoked - no non_responsive entry exists anywhere server-side.
Solution Steps
- In FeedbackLoop.recordDownloadFeedback, change validOutcomes from ['confirm', 'refute', 'non_responsive'] to ['confirm', 'refute', 'derive', 'rollback'] to match the server's real accepted vocabulary exactly.
- Apply the identical fix to the GitHub Action's entrypoint.mjs, which had its own separate copy of the same invalid outcome list.
- Run the SDK's full unit test suite.
Validation
[object Object]
Rollback
[object Object]
Ecosystem: nodejs
License: MIT
Last updated: Jul 6, 2026