Closed ohnotnow closed 6 years ago
I'm not sure but to me it looks like a deadlock state.
Process 1: php artisan dusk
. Runs AppServiceProvider and sets the file to enforce Foreign Key. This locks the file to ensure every database activity gets properly analyzed before committing to the sqlite file.
Process 2: Browser. The browser will hit AppServiceProvider in a separate process in parallel with the previous process and try to lock the file again. Because the previous process didn't finish yet (Browser is child of Process 1), the file is locked.
Since SQLite is a simplistic single-file database, the second process just assumes that the file is not writable because the first process locked it.
Again, I'm not sure but I think when you check for environment variable, Process 1 (php artisan dusk) might not be set to run as testing
, which means the database never gets changed by Process 1, which might be fine if you ensure every seed/factory that you do before running your Browser Test respects foreign keys without database enforcement.
@deleugpn yeah - the APP_ENV for phpunit and dusk are set to testing/local respectively so they can do their thing. I'm in the lucky spot where the dusk tests for the app I originally spotted this in are really just a basic 'happy path' walkthrough of the site + javascript popups and the like - not really the 'meat' of the app - otherwise it would probably fail when onDelete()'s weren't happening.
I'm just not sure why it worked in L5.4/dusk1.x if it's a deadlock as it worked much the same way. But I'm not sure if it's a framework thing, a dusk thing, or some other underlying component. It's even faintly possible if dusk2 is running a bit faster I'm just hitting a lock that I was just missing before.
I'm getting the same issue after upgrading. Multiple apps as well.
https://laracasts.com/discuss/channels/testing/after-upgrading-to-55-phpunit-fails-with-sqlite
Same problem here! If you need a project/case to test the error please contact me.
If anybody can create a clean installation that is capable of replicating the problem and posting the repository here, I'll take a look.
@deleugpn please see: https://github.com/acacha/duskSqliteErrorReadOnly
A project recently created (fresh Laravel installation I only added to simple models an migrations with a foregin key relation bettween the tables).
If you run:
php artisan migrate --database=sqlite_testing
It works but:
php artisan dusk
Give the readonly error!
We're experiencing the same problem. In our case we don't enable foreign keys, but simply run \Schema::hasTable('settings')
in one of our Service Providers. This also locks the database.
Also experiencing, but I have no idea why at this point.
@deleugpn ping or maybe someone else could check https://github.com/acacha/duskSqliteErrorReadOnly
Closing this issue because it's already solved, old or not relevant anymore. Feel free to reply if you're still experiencing this issue.
I have this same issue on L5.7. The tests fail on my machine but strangely everything runs ok on bitbucket pipeline. Did not manage to locate the difference in environments.
@hekin1 Please provide a minimal application to reproduce the issue.
Experimented a bit more, and now I nailed it down to this:
Hi,
Slightly edge-case setup I guess. But when using DatabaseMigrations with sqlite and enforcing foreign key constraints, dusk fails with a rather confusing error about the database being readonly. Plain phpunit still runs ok. L5.4/Dusk1.x ran ok with this setup too.
Clean L5.5 install, install/publish dusk as per. Database set to sqlite. Artisan make:auth just so there's something to migrate. Running dusk at this point works ok. But if you enable sqlite's foreign key constrains by adding the code below (as has been regular working practice until now) to your AppServiceProvider then you get the 'readonly' error.
results in:
I can work around it by checking for the app environment rather than purely checking for sqlite - but it's less than ideal as I'm sure it'll bite me at some point.
Anyway - it's maybe not a very common setup, but it caught me out.