Fosuserbundle: You have requested a non-existent service "fos_user.doctrine_registry".

[mrryanjohnston]

I just ran a composer install from within my project. This error is now produced when trying to do anything within the app:

ServiceNotFoundException in bootstrap.php.cache line 2119:
You have requested a non-existent service "fos_user.doctrine_registry".

I have "friendsofsymfony/user-bundle": "~2.0@dev", and "symfony/symfony": "2.6.*", in my composer.json. Let me know if there's any more context I can provide.

[abstractk]

Got the same. Please advise.

[rodmarzavala]

Same error here..
You have requested a non-existent service "os_user.doctrine_registry".
Running Symfony 3.0.1

[tianchaoc]

my error is :You have requested a non-existent service "fos_user.doctrine_registry".
500 Internal Server Error - ServiceNotFoundException

[orojasanchez]

I have the same problem, I am using symfony3 I could not solve the problem

[ad3n]

:+1: me too

[xabbuh]

Can you please check if the patch proposed in symfony/symfony#17554 will solve your issue?

[merk]

Short term fix is either roll back the commit or define an alias in your config.yml file:

services:
    fos_user.doctrine_registry:
        alias: doctrine

@xabbuh's fix will work for 2.7+, but not for 2.3.

[bakie]

@xabbuh fix will not work in 3.0+ as the method isStrict() is removed from Symfony\Component\DependencyInjection\Reference. See the upgrade docs https://github.com/symfony/symfony/blob/master/UPGRADE-3.0.md

[stof]

@bakie the patch is for 2.7. It will indeed be changed when applying it in newer branches

[xabbuh]

@merk For Symfony 2.3, you can try symfony/symfony#17555.

[Bordovsky]

Hi. How should I add @xabbuh 's fix into our project? We are using symfony 2.8 and would like to try it.

[cmmata]

@Bordovsky I'm using Symfony 2.8 and that fix works.

[xDaizu]

Same problem with

     "symfony/symfony": "2.7.*",
     "friendsofsymfony/user-bundle": "~2.0@dev",

@merk's fix worked :+1:

[Swahjak]

@merk's fix worked for me as well with ~2.0@dev and 2.7.*

[19eugen86]

@merk's fix works for me as well, thanks!

    "symfony/symfony": "3.0.*",
    "friendsofsymfony/user-bundle": "~2.0@dev"

[ad3n]

@xabbuh : i use dev-master and update composer and same. I got this issue

I'm using 3.X

[stof]

@ihsanudin the fix is not yet available in all branches of Symfony

[hgoertz82]

@merk's short term fix worked with symfony 3

[ReenExe]

Also exists like this:
[Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException]
The service "rqs.user_manager" has a dependency on a non-existent service "fos_user.entity_manager"

"symfony/symfony": "2.6.*",
"friendsofsymfony/user-bundle": "~2.0@dev",

Only need change to @fos_user.object_manager
And have theme error
So try use:

"friendsofsymfony/user-bundle": "dev-master##6ccff96434c0ac7fee077d1dce90966341dfd278"

[gondo]

how could this pass tests?
this is exactly the reason why i'm moving away form this bundle, one irresponsible bug can bring down whole application...

[gnsimoes]

I agree with @gondo .
This can cause serious problems.

[stof]

@gondo This is a bug in the master branch of the bundle (which is actually a bug undetected in Symfony for years). If you don't want any bug, don't run composer update blindly with constraints allowing unstable versions.

[gondo]

@stof what other option do i have with this bundle? latest stable version is v1.3.5 from Sep 4, 2014. also everywhere on the web (one example for all: http://symfony.com/doc/current/bundles/FOSUserBundle/index.html) it is recommended to use "~2.0@dev". i understand that bugs happens, what i don't understand is how it could pass any test. it does fail on cache clear process for me.

[stof]

@gondo the 2.x version has alpha tags at least.

And even then, this has been merged a few hours ago, so you could still have a lock file in the project using an older version than the buggy one.

[gondo]

@stof my project is fine, my CI setup does not let broken builds into production. however not everyone has setup like this to spot such issue in time. i'm just questioning the merge/test process of this very popular bundle. and questioning benefits this bundle brings vs the problems it cause.

[francoispluchino]

@gondo:

Pros: It avoids reinventing the wheel for managing users, groups, auth, reset password, and many other things...
Cons: stable releases do not come regularly

Sure, you can use an alpha version or the dev branch with the sha of commit in your root composer.json file.

[roundge]

Hi,
Same error with Symfony 2.8.2 and FOSUserBundle dev-master.
Adding an alias in services.yml works for me. thanks

[merk]

If you're using a @dev constraint for a bundle or library you must expect breakage. This is a simple fact of how development works. There is obviously a missing test to cover the path that caused this issue. Given this is a community bundle, we always welcome PRs that add features or test coverage.

This bug was not in the bundle and fixes for Symfony itself were merged within a day. (and a workaround was provided within hours).

[YetiCGN]

@gondo Any old smoketest should find that error, since it also occurs in the login procedure. So I doubt anybody deployed this to production. I side with @stof and @merk that you should be aware of such issues if you include master branch versions and have appropriate tests in place. For us it popped up in basic unit tests for the login procedure, so no biggy.

@stof: I ran composer update just now and it didn't fix the bug. What commit are you talking about? The service alias helps, though.
By the way, what is your timeline on a stable 2.0 release? ;) What needs to be done? Can anybody help?

[xabbuh]

@YetiCGN The fix was done in Symfony not in FOSUserBundle. So you would need to switch to a dev version of Symfony if you want to have that fix right now or rewind your commit of FOSUserBundle you rely on to a one before the merge of #1612.

[YetiCGN]

I see, thanks for the info!

[clytemnestra]

I'm using 2.8.* and got this issue. Is there any way without the alias?

[stof]

@clytemnestra use the dev version of Symfony 2.8 to have the fix, or lock FOSUserBundle to an older commit until Symfony 2.8.3 is released

[clytemnestra]

Oh, I see. Thank you. I'll use the alias until 2.8.3 and remove it then. Seems better than changing the composer.json.

[xDaizu]

I understand bugs happen; and a fix was provided very quickly, so I'm not mad or anything.

Still, I think it's about time for a stable 2.x release so there's a reasonable alternative to use "~2.0@dev", which is the recommended one in the documentation because there's not actually any other option. And "alpha" is not "reasonable stability for production" (actually, in my brain alpha pretty much equals dev, haha)

I'm thankful for this bundle, and I appreciate all the work done. I really do! But I also think you should put some time aside to release stable versions more often. To have new features is all nice and dandy but stability is cool, too. That being said, it is true that dev versions of this bundle tends to be VERY stable. But still, we need some assurance for our beloved composers (and clients) :tongue:

[picks44]

Totally agree with this. Official documentation recommend to use "~2.0@dev"...

[mrryanjohnston]

Thanks for the quick response. This workaround seemed to do the trick. Closing this since it's not a bug in FOSUserBundle.

Edit: Also thanks for fixing this in Symfony, @xabbuh.

[sad270]

@merk 's fix works for me too, thanks ! :)

"symfony/symfony": "3.0.*",
"friendsofsymfony/user-bundle": "~2.0@dev"

[xDaizu]

@mrryanjohnston is it not a bug in FOSUserBundle...? I mean, FOSUB is the one requesting a non-existent service, isn't it...? ^^U

[stof]

@xDaizu no. FOSUserBundle is defining this service (as an alias). But the container optimization performed by Symfony was buggy. It was properly detecting that the private alias could be dropped by replacing its usage by the alias target, but it was forgetting to actually replace the usage as a factory service.

[xDaizu]

@stof Oh, I see. :)

[gamelodge]

So now we know this is a bug in Symfony, and also know we need to wait for the fix to filter through from Symfony, we still allow this commit? should we not ensure stability even if it means coding to a bug in a dependancy and then once said bug is fixed we update accordingly?

I know this is a "Dev" branch which means that technically this commit is correct, but its also the recommended branch (with both alpha's not working for 3.0.1 at least for my me) so does that not change the "stability" factor?

[merk]

The workaround is to simply define the alias again in your application configuration until the next symfony point release. If this was a stable 2.0 release it would have been rolled back or worked around.

[xDaizu]

@merk We understand that, but I think that, as I stated before, most of the community see this as a warning sign for "we need a proper stable branch"

[AITG]

Shocking this still hasn't been fixed.

merk's patch works, but c'mon - this is a breaking change and should have been fixed by now, alpha or not.

[yeou]

Any idea when 2.8.3 will be released with the fix?

[stof]

@yeou I don't know. You need to ask Fabien about that (and he does not read this issue tracker)

[stof]

@AITG The fix has been merged in Symfony 3 weeks ago

[AITG]

@stof - Which version? I did a composer update 3 days ago and it still exhibited the problem, hence my post, whatever the version it should have come down the same channels that the bug came down in.

[ad3n]

@AITG : The problem come from Symfony it self, so you must be waiting symfony new release

[xDaizu]

@stof but was it already merged in a stable release for both LTS versions? because if not, we would be required to

run composer update blindly with constraints allowing unstable versions.

and then if _anything else fails_ we get scolded again... :sweat_smile:

[pachukeiner]

@merk fix worked (v3.0.1)!

[stof]

but was it already merged in a stable release for both LTS versions

no. It has been released in 3.0.2, but 2.3, 2.7 and 2.8 have not been released yet with the fix

[ad3n]

@stof : Are you sure? :+1: i will check on my project

[AITG]

@stof @ihsanudin - As I said in my previous post a few days back, the 2.7 branch hasn't been updated (since Jan 14th), so unless it comes in through another package (i.e. fos user directly - which it should be seeing as it was that which broke in the first place), it won't have been patched yet.

[xabbuh]

@AITG As @stof said the change was made in the 2.7 branch but wasn't part of any 2.7.x patch release since then. So you will have to rely on the 2.7.x-dev version or stick with the workaround @merk showed for the moment.

[stof]

• As I said in my previous post a few days back, the 2.7 branch hasn't been updated (since Jan 14th)

That's not true. the latest update of the Symfony 2.7 branch is 23 hours ago.

[AITG]

@stof - Someone needs to update the blog ;) - http://symfony.com/blog/category/releases

[stof]

@AITG you are confusing branches and releases.

[AITG]

Sorry, in that case I mention to say that there hasn't been a new release of 2.7.x code since the 14th of Jan (going off that page).

Either way, when I posted my previous post a week ago, I had just done an composer update on a 2.7.x project and the latest version that was bought down did not contain a fix.

[stof]

Sorry, in that case I mention to say that there hasn't been a new release of 2.7.x code since the 14th of Jan (going off that page).

I know there hasn't been any release. This is exactly what I said above: https://github.com/FriendsOfSymfony/FOSUserBundle/issues/2048#issuecomment-186143362

[sterichards]

Using the alias patch, I get the following:

PHP Fatal error: Uncaught Symfony\Component\Debug\Exception\FatalThrowableError: Fatal error: Call to protected DoctrineORMEntityManager_00000000607d38af0000000037ee855b28a0c7188fe871033e49ce7a85e414ea::__construct() from context 'appDevDebugProjectContainer' in /vagrant/app/cache/dev/appDevDebugProjectContainer.php:1114