A client that declared no extensions receives two results from different servers. One carries resultType "deferred", a value the client does not recognize. The other carries no resultType field at all. How should the client treat each result?
Select an answer to reveal the explanation.
Short Explanation
If you see an unknown word on a form, that's a red flag; a blank field from an older form version just means "the usual." So an unrecognized resultType is invalid, while a missing one is treated as "complete." The trap is swapping those two.
Full Explanation
Every result in 2026-07-28 must include resultType, and the core values are "complete" for a finished result and "input_required" for a multi round-trip interim result. Extensions may add further values, but only values from the core set plus those of extensions advertised in capabilities are supported, and a resultType of any value the client does not recognize must be considered invalid. Since this client declared no extensions, "deferred" is invalid. Backward compatibility drives the second rule: servers implementing earlier protocol versions never sent resultType, so clients must treat an absent resultType as "complete". Swapping the two rules would break every legacy server while accepting unknown result shapes from modern ones. Treating both as input_required invents a retry loop with nothing to answer, since there are no inputRequests to fulfil. Rejecting the result that lacks the field ignores the explicit compatibility rule and would cut off older servers. Exam caveat: a client that does declare the Tasks extension must be prepared for resultType "task", which is recognized because it advertised that extension. Operational check: feed the client a result with an unknown resultType and one with none, and confirm the first surfaces an error while the second is processed as a normal result.