by installing sdx i get:
[success] Successfully uninstalled: sdx, sdx_vite, sdx_devel, sdx_react, sdx_npm
bash-5.1$ php -d memory_limit=1G ./vendor/bin/drush.php pm:install sdx
In ExceptionHandler.php line 89:
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT 1 F
ROM information_schema.tables WHERE ("table_schema" = :db_condition_placeho
lder_9) AND ("table_name" = :db_condition_placeholder_10) AND ("table_type"
= :db_condition_placeholder_11); Array
(
[:db_condition_placeholder_9] => xxx_drupal_xxx
[:db_condition_placeholder_10] => a_config
[:db_condition_placeholder_11] => BASE TABLE
)
In PdoTrait.php line 109:
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
bash-5.1$ php -d memory_limit=1G ./vendor/bin/drush.php pm:install sdx
[notice] Already installed: sdx
bash-5.1$ php -d memory_limit=1G ./vendor/bin/drush.php sdx:resolve
In ExceptionHandler.php line 89:
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: INSERT INT
O "a_cache_bootstrap" ("cid", "expire", "created", "tags", "checksum", "dat
a", "serialized") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_
1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placehold
er_4, :db_insert_placeholder_5, :db_insert_placeholder_6) ON DUPLICATE KEY
UPDATE "expire" = VALUES("expire"), "created" = VALUES("created"), "tags" =
VALUES("tags"), "checksum" = VALUES("checksum"), "data" = VALUES("data"),
"serialized" = VALUES("serialized"); Array
(
[:db_insert_placeholder_0] => hook_data
[:db_insert_placeholder_1] => -1
[:db_insert_placeholder_2] => 1786308556.112
[:db_insert_placeholder_3] =>
[:db_insert_placeholder_4] => 0
[:db_insert_placeholder_5] => a:0:{}
[:db_insert_placeholder_6] => 1
)
In PdoTrait.php line 109:
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
Comments
Comment #2
lblabr commentedusing drush i always get these database things. that not happend before ... (with other modules)
drupal 11.4.5
Comment #3
vzsigmond commentedFixed in 1.0.0-alpha13 (with the first half already in 1.0.0-alpha12) - please update and confirm.
What was wrong, in your terms:
1. "by installing sdx i get [gone away]": installing/uninstalling SDX modules used to re-resolve the whole npm dependency graph against registry.npmjs.org inside pm:install - minutes of serial network I/O during which the idle MySQL connection exceeded your host's wait_timeout and died. As of alpha13 the install path does zero network - resolution only happens in drush sdx:resolve - so this cannot occur anymore. Module installs even work fully offline now.
2. "sdx:resolve [gone away]": two phases were at fault. The npm install child process is covered since alpha12 (the connection is kept alive while it runs), and as of alpha13 the registry-resolution phase fetches concurrently and caches to the database as responses arrive, so the connection stays active there too - plus the whole phase drops from minutes to seconds.
The leftover errors you saw on retries ("already an existing entry hook_data", drush en failing) were debris of the dead connection - run
drush cronce after updating and they're gone. After updating, rundrush sdx:resolveonce; the status report now has an "SDX: Dependency lockfile" row that tells you when that's needed.Comment #4
lblabr commentedupdate to -alpha13
drush en sdx works now.
drush sdx:resolve runs some minutes without showing somthing on the shell
after a while a lot database output is shown (in log 15,5MB)
starting with:
In ExceptionHandler.php line 89:
and end up with:
Comment #5
vzsigmond commentedThanks for the fast retest - that log dump was exactly what was needed. This was a different failure than the previous ones despite the same error code: MySQL also reports "server has gone away" when a single INSERT exceeds max_allowed_packet, and alpha13's resolver cached the full registry document per package - @types/node is over 15 MB serialized, which your host's packet limit rejected, killing the connection.
Fixed in 1.0.0-alpha14: SDX now fetches npm's abbreviated document format (the same one npm/pnpm use) and caches only the fields the resolver reads - @types/node drops from >15 MB to ~550 KB, resolves in a fraction of a second, and the minutes of silent downloading are gone. You should also no longer need the raised memory_limit for sdx:resolve. Please update and confirm.
Comment #6
lblabr commentedSDX Doctor
==========
Comment #7
vzsigmond commentedGreat, this output confirms the database bug is fixed.
What you're seeing now is separate, and the sdx:doctor output shows the cause: no framework module and no bundler module are enabled. The build ran against a leftover build-config dir from before, and without sdx_react enabled its vite plugin has no pinned version in sdx.lock - so npm fetched the newest @vitejs/plugin-react (6.x, which wants vite 8) and hit the peer conflict. To get going:
That said, you've exposed two things we'll harden regardless: the build will stop emitting unpinned ("*") dependencies into the generated package.json (it will fail with an actionable message instead), and sdx:build will skip stale build configs for frameworks whose module isn't enabled.
Thanks for the thorough reports!
Comment #8
lblabr commentedlooks fine now. i need to solve the base_dir error
Comment #9
lblabr commented