Symfony 6.3@dev Unexpected ini_set(): Session ini settings cannot be changed after headers have already been sent #49387
Comments
|
Seems #49097 is your culprit. Don’t know why though ¯\_(ツ)_/¯ |
|
@MatTheCat That is really strange as we are using default session handler and not a PDO handler as I think 🤔 But did not yet test it out if that PR make the CI fail. |
|
if have the same error i dont know how to require symfony at this specific commit. If you can give a hint, i would try it. |
|
The backtrace is interesting thanks. Because I see two possible fixes:
/cc @alli83 in case you'd be up to have a look :) |
|
yes if no one is ont it already, I would be glad to have a look on it |
|
@nicolas-grekas yes it's possible de register the service as a listener. By launching it seems, indeed, that the error no longer occurs. is it better to make a first PR only for the PdoSessionHandlerSchemaSubscriber ? |
|
It should be possible to register a subscriber as a listener, right? |
|
it's just config in doctrineBundle and change doctrine.event_listener but now it's used as a listener the method checking if sessionHandler variable is set and not null won't be called. so I think we just have to add a quick check. or am I missing something ? |
|
I propose renaming all
|
|
@nicolas-grekas thank you for the clarification on the direction to take |
… in favor of listeners (alli83) This PR was merged into the 6.3 branch. Discussion ---------- [DoctrineBridge] deprecate doctrine schema subscribers in favor of listeners | Q | A | ------------- | --- | Branch? | 6.3 | Bug fix? | yes | New feature? | no | Deprecations? | yes | Tickets | Fix #49387 | License | MIT | Doc PR | As `@nicolas`-grekas explained in #49387 (comment) : " Because PdoSessionHandlerSchemaSubscriber is registered as a subscriber, ContainerAwareEventManager must instantiate it to know which events should be listened for. This triggers the instantiation of the session.handler service, which is a NativeFileSessionHandler, and this notice when this is done after headers have been sent." It was therefore decided to change all the doctrine schema subscribers in favor of listeners in order to avoid this kind of problem. Being already present before Symfony 6.3, `MessengerTransportDoctrineSchemaSubscriber`, `DoctrineDbalCacheAdapterSchemaSubscriber` and `RememberMeTokenProviderDoctrineSchemaSubscriber`have been deprecated. TODO: - [ ] : update DoctrineBundle => in progress Commits ------- 787d569 [DoctrineBridge] deprecate doctrine schema subscribers in favor of listeners
|
I tested it locally as we currently has another error with Thx for fixing this 👍. |
…s to ContainerAwareEventManager (alli83) This PR was merged into the 6.3 branch. Discussion ---------- [DoctrineBridge] Deprecate passing doctrine subscribers to ContainerAwareEventManager | Q | A | ------------- | --- | Branch? | 6.3 | Bug fix? | no | New feature? | no | Deprecations? | yes | Tickets | Fix #49586 | License | MIT | Doc PR | Following issue #49586, this PR aims to deprecate passing doctrine subscribers to ContainerAwareEventManager. As mentioned, "[#[AsDoctrineListener]]... is a way better alternative anyway." Following #49387 (comment), in PR #49610 DoctrineSchemaSubscribers have already been deprecated in favor of listeners. Commits ------- c08780e [DoctrineBridge] Deprecate passing Doctrine subscribers to ContainerAwareEventManager, use listeners instead
|
I'm running again into this issue not sure since when as our CI against
It can be reproduced again with: git clone [email protected]:sulu/sulu.git
cd sulu
composer config minimum-stability dev
composer update
env DATABASE_URL="mysql://root:[email protected]:3306/sulu?serverVersion=8.0.27&charset=utf8mb4" composer bootstrap-test-env
env DATABASE_URL="mysql://root:[email protected]:3306/sulu?serverVersion=8.0.27&charset=utf8mb4" composer test |
|
The issue is in gedmo/doctrine-extensions/src/Tree/Entity/Repository/AbstractTreeRepository.php, which calls On your side, you might want to double check why the native session storage is used for tests, while the mock one should be, isn't it? |
|
Thx that you already did have a look at this. Did sadly not yet have time for a deeper debug and create the issue as discuss. Just a question which did popup when I see the stacktrace, should the PDOSessionListener not only be registered when be used? Our tests normally should run on mocked session:
Does I understand it correctly the PDOSessionListener does inject the SessionHandler which has the NativeSessionStorage in it which access the session inside its constructor? Where is the |
|
Why I think it would be good if the PDOSessionListener is only registered when PDO session is used. I currently found a workaround to fix the issue which did only appear with the framework:
session:
storage_factory_id: session.storage.factory.native
handler_id: ~ # this was missing
when@test:
session:
storage_factory_id: session.storage.factory.mock_file
handler_id: ~ # this was missingThis way the error seems to disappear. |
|
Getting the same error after upgrading to sf 6.3 yesterday, when I run error: In NativeFileSessionHandler.php line 49:
Warning: ini_set(): Session ini settings cannot be changed after headers have already been sentError does not happen when visiting the site. I have 2 doctrine listeners, registered with #[AsEntityListener(event: Events::prePersist, method: 'prePersist', entity: Invoice::class, lazy: true)]Any hint on where to look ? logs: |
|
@hellomedia how doey your |
framework:
session:
handler_id: session.handler.native_file
save_path: "%kernel.project_dir%/var/sessions/"Thanks @alexander-schranz . As you suggested, setting @nicolas-grekas Is this the right way to handle this ? |
@alexander-schranz maybe I could add a tag for PdoSessionHandler and target only this one or check and process it in a compiler pass in DoctrineBundle ( @nicolas-grekas what do you think? |
|
No need for a new tag, but an attribute on the existing one would be nice, yes. |
|
@alli83 should I open a separate issue ? NB: I can try to help with the PR but this is a bit outside of my comfort zone... |
|
sorry for the late reply. if it's not too late, I'm happy to have a look at it. |
|
@alli83 thanks. It's not blocking for me, as But I wonder if everyone on 6.3 will experience this. In which case a fix would probably make sense. |
|
In case this info is helpful to someone else, I found the issue to my problem. I was echoing something in As I now understand, echoing something in |
Symfony version(s) affected
6.3.0@dev (6.2.*@dev works)
Description
Something seems to be merged into Symfony 6.3 branch which currently let our CI fail on it with:
So it looks some changes in the Session handling. Not sure what it could be, shortly looked at the merged Pull Requests I didn't see why it is happening.
I tested out
6.2.*@devthere all seems to work still like expected.If somebody have a hint which PR could have introduced the error let me know, happy to test it out.
How to reproduce
Possible Solution
Workaround see: #49387 (comment)
Additional Context
The change need to be somewhere between Januaray 25 and February 6 and only Symfony 6.3:
The text was updated successfully, but these errors were encountered: