Fatal crash: NSFileHandleOperationException in MediaFileHandle.append(data:) (line 74)

[hayden-cantina]

Overview

We’re seeing a production crash on CachingPlayerItem 2.2.0 (cc00381e252ac9b2a7b691e1da6a598bd7517bdc):

Fatal Exception: NSFileHandleOperationException
at -[NSConcreteFileHandle writeData:]

The crash resolves to:

• MediaFileHandle.append(data:)
writeHandle.write(data) at:
  

  CachingPlayerItem/Source/MediaFileHandle.swift

  Line 74 in cc00381

  writeHandle.write(data)

Called from:

• ResourceLoaderDelegate.writeBufferDataToFileIfNeeded(forced:):
  

  CachingPlayerItem/Source/ResourceLoaderDelegate.swift

  Line 227 in cc00381

  fileHandle.append(data: bufferData)

Request

Would you consider handling NSFileHandleOperationException from this write path and routing it through the existing failure flow (downloadFailed(with:)) instead of crashing the process?

A minimal approach would be an Objective-C safe-write wrapper (@try/@catch) around seekToEndOfFile + writeData, returning an NSError to Swift, then calling downloadFailed(with:) when write fails.

Thank you for your consideration.

[hrebinik]

I am hitting the same crash in production on CachingPlayerItem, same path: MediaFileHandle.append(data:) (line 74) called from ResourceLoaderDelegate.writeBufferDataToFileIfNeeded(forced:).

In our case the underlying NSFileHandleOperationException reason is:

*** -[NSConcreteFileHandle writeData:]: No space left on device

So the trigger is the device simply running out of storage while the player buffers to disk — a recoverable, expected device condition rather than a logic bug, which makes crashing the whole process especially undesirable.

+1 for the proposed fix: wrapping seekToEndOfFile + writeData in an Obj-C @try/@catch safe-write helper that returns an NSError to Swift, then calling downloadFailed(with:) on failure. That would let the app surface the out-of-space case (or stop caching) instead of going down.

Thanks for considering it!