TYPO3 Core

Ernesto, I hope you don't mind me adding you as a watcher to this. I'm not sure who to pick as a reviewer in Gerritt...perhaps you can suggest someone?

this is a regression from 6.2.0? could you confirm?

Thanks. I started noticing it immediately after trying the upgrade to 6.2.1, but I'm going to check out the 6.2.0 tag and double-check. I'll let you know what I find out.

If it helps narrowing down the problem: I have had this problem since 17. March (According to my CI-server build log); this error wasn't there on the build done 11. March.

I played around a bit, and determined with a little more detail the behavior: it is indeed new for 6.2.1, and it only occurs if "System caches" are flushed prior to running cli_dispatch.phpsh.

$ cd typo3_src
$ git describe --tag
6.2.0
$ cd ../
$ typo3/cli_dispatch.phpsh scheduler
    [NO ERROR]
$ typo3/cli_dispatch.phpsh cleartypo3cache all [DataHandler cache clearing script]
$ typo3/cli_dispatch.phpsh scheduler
    [NO ERROR]
$ cd typo3_src
$ git checkout TYPO3_6-2-1
Previous HEAD position was 4924c9e... [RELEASE] Release of TYPO3 6.2.0
HEAD is now at 4707e42... [RELEASE] Release of TYPO3 6.2.1
$ cd ../
$ typo3/cli_dispatch.phpsh cleartypo3cache all
$ typo3/cli_dispatch.phpsh scheduler
    [ERROR HERE, assuming cache has been cleared]
$ typo3/cli_dispatch.phpsh scheduler
    [NO ERROR]
$ typo3/cli_dispatch.phpsh cleartypo3cache all
$ typo3/cli_dispatch.phpsh scheduler
    [ERROR AGAIN]

You'll notice in my sample I used a cache clearing CLI script for illustrative purposes. The problem also manifests if you instead "Flush system caches" from the TYPO3 back end.

So, my submitted patch may be just a band-aid solution? At any rate, it seems to solve the problem -- what do you guys think?

FYI: This is also happening to me in TYPO3 6.1.8!

Gabe Blair wrote:

Starting in 6.2.1, if you try using the CLI dispatcher (assuming you've got your BE user set up, etc.), e.g.:
[...]

... you get something like this back (markup removed for clarity:
[...]

Looks like AbstractUserAuthentication::start() tries to send HTTP headers, which throws an exception (or warning, maybe?) that can't be logged because user has no ip address (a different can of worms?). A quick check for CLI context before sending header() output seems to do the trick to work around this. I'll see if I can get a patch submitted.