Bug: Loom import to Clips stores a truncated video and marks it "ready"

[pdmarf]

Summary — Importing a Loom recording downloads only a small fragment (~300 KB for a 7-minute source), uploads that fragment, and marks the recording ready. Result: working audio + thumbnail, but no playable video. No error is raised.

Environment — Clips, self-hosted (Docker), @agent-native/core 0.179.0, S3-compatible storage, PGlite.

Steps to reproduce

1. "Import from Loom" with a public share link to a ~7-minute recording.
2. Wait for the job to finish (completes within seconds).
3. Open the recording.

Expected — Full video downloaded and stored; plays end to end.

Actual — Audio + thumbnail fine, video doesn't play. Job reports success, marks recording ready. Stored file is ~300 KB — far too small for 7 minutes — so it holds (at most) an audio track and no usable video.

Evidence (logs, redacted)
[loom-import] download complete { recordingId: '', bytes: 309826, mimeType: 'video/mp4' }
[loom-import] reupload complete { videoUrl: 'https:///…//…mp4' }
[loom-import] recording ready { recordingId: '' }
bytes: 309826 is the key line — the whole "video" fetched for a 7-minute source before declaring it ready.

Likely cause — Loom serves segmented/streamed media, not a single MP4; the connector looks to have fetched only one segment and treated it as complete. There's also no size/duration sanity check — a ~300 KB result for a multi-minute recording is
accepted, hiding the failure.

[steve8708]

Thanks for the detailed report and the byte-count evidence. We fixed Loom imports so Clips rejects partial responses and validates the downloaded video against Loom’s reported duration before marking it ready. Unverified media now falls back to the Loom player instead of storing a broken file. This should be fixed in the next release. If it still reproduces after upgrading, please share the exact Clips/core version, deployment commit, and the Loom import download bytes and duration details.