From memory this was true in J3 as well. I used to see it with a failed patchtester install and had to follow the steps you describe to resolve it.

I really dont see how this is a release blocker - its a bug but hardly prevents normal usage of Joomla which is what a release blocker should be.

@brianteeman I’ve added release blocker label as suggested by @wilsonge .

When people migrate to J4 they probably will install many extensions by discover. So it should befixed before release.

If they have to do it by discover then we will have really messed up the upgrade - won't we?

When people migrate to J4 they probably will install many extensions by discover. So it should befixed before release.

How about if it’s a known bug in 3.x that it be fixed in 3.x (if it can be done without B/C issues) instead of reporting and fixing bugs against only 4.0?

And +1 on Brian, if you’re using discover install then the release process was messed up massively. Of course since core makes no promises about upgrades until stable, nobody is going to know that answer until 4.0.2 comes around.

Of course since core makes no promises about upgrades until stable, nobody is going to know that answer until 4.0.2 comes around.

@mbabker This is wrong. We we will promise updatability between 4.0 version beginning with beta-1. And that we don't promise before doesn't mean we aren't testing before.

@brianteeman and @mbabker
When I am developing an extension, I always use discover. What's wrong about ist? Why do we have it, if it may not be used?
If you think it is wrong or superfluous - remove it.
I wrote this because "normal users" do not easily find these issues by chance and most of developers know how to make workarounds but do not write issues.

@chmst we misunderstood each other I think - trying again

When people migrate to J4 they probably will install many extensions by discover.

Why would they install many extensions by discover because they have migrated?

As supporter I see users who have extensions but have lost their easy-to-install .zip files and we say them "use discover" if necessary.
I think that this is needed often when migrations are made. Maybe I am wrong but that's not important. Let's try to fix it and basta.

You really shouldnt need to use discover on an upgrade - if you do then the upgrade code is wrong and needs fixing.

And as far as I recall this discover failure exists in j3 as well so it should be fixed there

@chmst Could you test if the issue exists in J3, too, and if so, just remove "[4.0] " from the beginning of the title and change "Build" from "staging" to "4.0-dev" in the issue tracker, and all is fine with the issue.

Regarding release blocker or not: For me it is not a blocker, but maybe @wilsonge can comment why he asked me to add the label ;-)

Indeed, the same in 3.9.

@wilsonge Any reason not to fix it in 3 but wait for 4? E.g. db drivers: Do they support transactions in staging branch, too, or only in 2.0-dev of the framework package? From my point ov view the installer should use sql transactions so it can roll back when an error breaks the installation somewhere in the middle.

From my point ov view the installer should use sql transactions so it can roll back when an error breaks the installation somewhere in the middle.

Transaction support exists in the database API in 3.x for all supported drivers IIRC. Problem is core lacks proper error handling and someone would need to take the time to add transaction support to relevant parts of the API AND appropriate success/error handling (transaction commit/rollback) at the same time.

I agree should be fixed in 3.x, maybe we cam try/catch the db queries but working on installer code is far from fun. I removed the release blocker label. A workaround is to unstall the extension as far as I know.

Is this pr relevant/helpful #21363