fix(web): accept nullable Depot component media types - #690
Conversation
jmagar
left a comment
There was a problem hiding this comment.
Manual adversarial review completed against the two-file diff, the live production response shape, and the Rust Artifact model. The production response contains currentRevision.components[].mediaType=null for components without detected media types, and the canonical Rust model represents media_type as Option. Normalizing that null to the existing optional catalog-text projection is the narrow contract-alignment fix. I checked for adjacent nullable fields in the same live artifact response; the other schema-declared nullable fields are already handled by optionalCatalogText or passthrough fields. No authorization, identity, catalog-preflight, or mutation semantics change. Regression coverage now exercises the nullable mediaType path. Local gates are green: Depot client 55/55, Library 14/14, full Gateway Admin unit suite, ESLint, production build/TypeScript/bundle checks, and git diff --check.
Summary
Fix a live Library artifact-detail failure discovered while validating #685 in production.
Live reproduction
After #685 was merged and deployed, authenticated /library/ browsing and search were healthy, but opening the real chrome skill detail produced a client-side incompatible artifact detail response. The successful depot.artifacts.get response contains components whose mediaType is JSON null when no media type is detected. The Rust Artifact model defines this field as Option, so null is valid.
Fix
Normalize currentRevision.components[].mediaType null to undefined, matching the existing nullable catalog-text behavior and the TypeScript optional field. No other validation is weakened.
Verification
This is a two-file, frontend-only contract-alignment hotfix.