mirror of
https://github.com/logos-co/logos-plugin-qt.git
synced 2026-08-27 08:51:07 +00:00
Dario Gabriel LipicarandClaude Opus 5
fa68922404
The void arm discarded the dispatch reply. `value = QVariant(true)` was
unconditional: the JSON was parsed, then thrown away, so a provider answering
{"code":"invalid_args", ...} reached the caller as a successful void call.
Invisible until the providers gained something to refuse with. With the arity
upper bound in place (logos-cpp-sdk #150, logos-rust-sdk #50) the provider DOES
refuse `doVoid("junk")` -- the built module carries the `expected 0 arguments,
got ` literal, checked in the exact store path the failing run consumed -- and
the conformance cell still reported `true`, on both providers and all three
consumers. The twelve cells of the non-void arity cases went green in the same
run; these six did not, because their refusal died here rather than at the
provider.
Which is the same defect one layer down from the one the arity work started
from: an answer the caller cannot distinguish from a real one. There the
provider dropped an argument and answered anyway; here the provider refused
correctly and the glue reported success.
The closed set is the one logos-qt-sdk's consumer detector uses --
dispatch_failed / invalid_args / unknown_method -- matched only on an OBJECT
carrying a string `code`. A void method whose provider legitimately answers an
object is unaffected, and there is no such method: the contract says it returns
nothing. An ordinary reply still answers `true`; this is a branch, not a
replacement, and the test pins both sides.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>