And also don't assert that there are no buffers queued up when handling an EOS event. The pad's streaming thread might've already received a new stream-start event and queued up a buffer in the meantime. This still leaves a race condition where the srcpad task sees all pads in EOS state and finishes the stream, while shortly afterwards a pad might receive a stream-start event again, but this doesn't seem to be solveable with the current aggregator design. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2769>