TYPO3 Core

The Exception in the method write($string) seems being correct according to the StreamInterface, nevertheless it had to be thrown conditional and not always.

Here is the method in the StreamInterface:

    /**
     * Write data to the stream.
     *
     * @param string $string The string that is to be written.
     * @return int Returns the number of bytes written to the stream.
     * @throws \RuntimeException on failure.
     */
    public function write($string);

and below is shown how it's implemented in TYPO3:

    /**
     * @param string $string
     * @throws \RuntimeException on failure.
     */
    public function write($string)
    {
        throw new \RuntimeException('Cannot write to a ' . self::class, 1538331833);
    }

Following is my workaround to get it running:

    /**
     * @param string $string
     * @return int Returns the number of bytes written to the stream.
     * @throws \RuntimeException on failure.
     */
    public function write($string) : int
    {
        // throw new \RuntimeException('Cannot write to a ' . self::class, 1538331833);
        return strlen($string);
    }

Having discovered the trait https://github.com/guzzle/psr7/blob/148492f9e2e1524317a8aa60875f5b59517a9374/src/StreamDecoratorTrait.php which I did miss before, I see that the implementation in TYPO3 just by extending GuzzleHttp\Psr7\LazyOpenStream might be wrong.

The class LazyOpenStream serves as stream-wrapper and just returns what a stream-class is returning. Therefore any streams should be transferred as argument and not by extending the class.

Ok, guzzle/psr7 2.0-dev declares LazyOpenStream final. That's why it fails - we can't extend that class anymore.

This did not pop up in core testing yet, since we don't install -dev dependencies in our 'composer max' suites, and you probably shouldn't, either. Please stick to non-dev dependencies, core gives no guarantees whatsoever on this.

Of course, we should still change our SelfEmittableLazyOpenStream to deal with this dependency change, but it's not a blocker (currently, at least until 2.0.0 is out). For v10, we might be better off with defining guzzle/psr7 2.0 as conflict and adapt only v11 to be later compatible with guzzle/psr7 when 2.0.0 is released.

Easiest solution for both v10 and v11:

v10:
composer --req guzzle/psr7:^1.4.0

v11:
composer --req guzzle/psr7:^1.7.0

Both are the current lower bounds given by current v10 / v11 guzzlehttp/guzzle dependency.

This will deny 2.0 and also declares that we actively use guzzle/psr7 as dependency, which we do, since we extend one of its classes.

Agreed?

Above notes are more for the 'final' report from https://forge.typo3.org/issues/91826#note-3 - still unsure if there is more todo. I'd say we should block 2.0 for now, then see what happens. ok?

Sounds reasonable to block v2.0 first as quick fix.
I think an update should be target in mid-term though.
I haven't verified the differences between the versions so I don't know if v1.x has really disadvanteges.
Christian, you described it more detailed how to handle it, that's completely fine I think.

Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/69667

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/69668

Pushed patches for master, v10 and even v9 since a guzzlehttp/psr7 2.0.0 would break v9 otherwise.

David, would you like to test that? It should actively downgrade your guzzlehttp/psr7 to 1.something, probably 1.8.2.

The method write($string) still has to be changed.
Btw. according to the interface it must throw an exception but return int if I remember correctly.