What
The Node SDK types reject a network config that the Rust backend accepts.
sdk/node/src/state-aware-types.ts:158-165
export interface LxcUnrestrictedNetworkConfig {
enforcementMode?: LxcFirewallEnforcementMode;
defaultPolicy?: Extract<NetworkConfig['defaultPolicy'], 'allow'>;
allowedHosts?: never;
blockedHosts?: never;
}{ network: { allowedHosts: [] } } matches neither arm of LxcNetworkConfig:
LxcUnrestrictedNetworkConfig forbids the key outright via never, and an
empty array is still a present key.LxcRestrictedNetworkConfig requires enforcementMode, which is absent.
The Rust side treats an empty list as "no restriction expressed" and accepts it,
so the two sides disagree about a value a caller can easily produce -- an
allowedHosts array built by filtering or spreading, which happens to come out
empty.
Why it matters
This is a contract defect, not a typing nit: the SDK is the published surface,
and it refuses at compile time a document the engine would honor. A caller
building the list dynamically has to special-case emptiness to satisfy the
types, which is exactly the sort of accidental complexity the typed surface is
supposed to remove.
Fix
Pick one and make both sides say it:
- Widen the TS types so a present-but-empty restrictive array is legal on the
unrestricted arm, or
- Reject empty restrictive arrays in Rust so the engine matches the published
types.
Option 1 preserves current engine behavior and is the smaller change; option 2
is defensible if an empty allowedHosts should be read as a mistake rather than
as "no restriction". That is a product decision, which is why this is an issue
rather than a change in PR #849.
Provenance
Reported by Copilot in a suppressed comment on PR #849, verified against source.
What
The Node SDK types reject a network config that the Rust backend accepts.
sdk/node/src/state-aware-types.ts:158-165{ network: { allowedHosts: [] } }matches neither arm ofLxcNetworkConfig:LxcUnrestrictedNetworkConfigforbids the key outright vianever, and anempty array is still a present key.
LxcRestrictedNetworkConfigrequiresenforcementMode, which is absent.The Rust side treats an empty list as "no restriction expressed" and accepts it,
so the two sides disagree about a value a caller can easily produce -- an
allowedHostsarray built by filtering or spreading, which happens to come outempty.
Why it matters
This is a contract defect, not a typing nit: the SDK is the published surface,
and it refuses at compile time a document the engine would honor. A caller
building the list dynamically has to special-case emptiness to satisfy the
types, which is exactly the sort of accidental complexity the typed surface is
supposed to remove.
Fix
Pick one and make both sides say it:
unrestricted arm, or
types.
Option 1 preserves current engine behavior and is the smaller change; option 2
is defensible if an empty
allowedHostsshould be read as a mistake rather thanas "no restriction". That is a product decision, which is why this is an issue
rather than a change in PR #849.
Provenance
Reported by Copilot in a suppressed comment on PR #849, verified against source.