Commit graph

4 commits

Author SHA1 Message Date
KhooLy
c2b0e610ec Plan Discover per selected catalog 2026-07-10 13:53:39 +03:00
KhooLy
90d13d9983 Consolidate addon resource parse+plan into a single core call
Extracts parse_addon_body (returns a ParsedAddonBody enum instead of
always serializing to a JSON string) so the existing three-hop path
(parseAddonResourceResult -> wrapAddonResourceResponse ->
resourceParsePlan, still used by subtitles.ts) and the new single-call
parseAndPlanAddonResource share the same parsing logic instead of
duplicating error-envelope construction.

Removes the now-redundant wrapAddonResourceResponse FFI method. Tests
assert the combined call produces byte-identical output to the old
three-step pipeline.

Pairs with fluxa-desktop's matching addonManifest.ts/fetchPlanning.ts
change.
2026-07-09 21:29:29 +03:00
KhooLy
4ce837b125 test(ffi): add checked-in core_invoke method fixture + routing regression test
Per the robustness plan's §7. The plan's main suggestion — a
core_methods! table macro generating ffi.rs's route_* functions — was
skipped: ffi.rs's ~115 methods have heterogeneous call shapes (0-arg,
single string arg, multi-field object arg, some routed straight to a
domain function, some with inline argument massaging first), and
CLAUDE.md already records the project's own assessed judgment that
consolidating the three FFI surfaces isn't worth the rewrite risk —
that reasoning applies just as much to a macro-generated version of
one of those three surfaces.

Implemented the plan's other, explicitly "cheap middle ground"
suggestion instead: tests/wire/core_invoke_methods.txt checks in the
current list of all 114 method names route() recognizes (extracted
from ffi.rs's match arms), and a new test
(ffi::tests::every_known_core_invoke_method_still_routes) calls
core_invoke(method, "{}") for each and asserts the error kind isn't
unknown_method. This doesn't validate each method's business logic —
only that the name is still wired to some router — but that's exactly
enough to turn a renamed or deleted method from a runtime "no such
method" surprise on a platform this repo can't see into a test failure
here. Verified it actually catches drift by temporarily adding a bogus
method name to the fixture and confirming the test fails.

core_capabilities_json generation from the method table (the plan's
second §7 bullet) doesn't apply here: core_contract.rs's
CoreCapabilitySet is a small hand-curated set of platform feature
flags (http/storage/auth/player/plugins/torrent/local_stream/
notifications), not a per-method availability list — there's no
natural 1:1 mapping from the 114 routed methods to those 8 flags to
generate from.
2026-07-07 15:06:54 +03:00
KhooLy
2439bb3ba6 test: add golden wire fixtures and a headless-engine dispatch fuzz target
Per the robustness plan's §8: a tests/wire/ directory holds one real
AppAction input per representative action family, each paired with a
checked-in golden DispatchResult captured from an actual dispatch (a
new #[cfg(test)] wire_fixtures_match_golden_dispatch_output test
compares against it, with UPDATE_WIRE_FIXTURES=1 to regenerate when a
change is intentional). Any future camelCase/field drift on the
dispatch/completeEffect wire now fails in this repo instead of surfacing
as a silent Android/desktop regression.

Also add fuzz/fuzz_targets/engine_dispatch.rs, feeding arbitrary bytes
into both headless_engine_dispatch_json and
headless_engine_complete_effect_json against one engine handle — this
is the one path in the crate that runs global engine-mutating logic
without a catch_unwind guard on the desktop call path, so it's the
highest-value fuzz target missing from fuzz/. Exposes the four
headless_engine entry points as `pub` (still unreachable outside the
crate except through the fuzzing-gated `fuzz_targets` re-export module)
following the same pattern already used for parse_manifest and the
content_identity helpers.
2026-07-07 14:28:48 +03:00