mirror of https://github.com/ospab/ostp.git
ospab
d822f48891
All three on-disk config.json shapes (client, server, relay) used to be declared locally inside ostp/src/main.rs, invisible to any other consumer — which is exactly how ostp_client::migrate ended up matching against loosely typed serde_json::Value instead of a real schema, with no guarantee its hand-built output actually matched what the CLI parser expected. Moved every one of those definitions (AppMode, UnifiedConfig, ServerConfig, RelayServerConfig, ClientFileConfig, TunConfig, ExcludeConfig, MuxConfig, TransportConfigRaw, ApiConfig, FallbackCfg, ListenConfig, UserConfig) into ostp_client::config — the same file that already held the runtime ClientConfig/OstpConfig/etc. main.rs now imports them instead of re-declaring them (`ClientFileConfig as ClientConfig` to avoid colliding with the runtime ClientConfig, which stays separate on purpose: it's the engine's internal shape — handshake/io timeouts and the like a user never sets in config.json — built FROM one of these via the mapping in run_client_directly, not the same thing). ServerConfig.dns is now Option<serde_json::Value> rather than Option<ostp_server::dns::DnsConfig> — ostp-client doesn't (and shouldn't) depend on ostp-server just to name that type. main.rs, which already depends on both crates, deserializes it right before handing it to run_server(). cmd_migrate now proves its output against this schema before ever writing to disk (serde_json::from_value::<UnifiedConfig>(migrated)) — a migrator/ schema drift is now a hard error at migrate time, not a corrupted config.json discovered later. Added a matching unit test (every_migrated_output_matches_the_canonical_schema) that exercises this same check on all three migration paths (modular, legacy-flat, server). |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| test_udp.rs | ||