If Drupal sends a query to MySQL which is too big you never get informed about that if you use the database driven watchdog because it's too big for the watchdog as well.

In our case this is critical because inserts into cache_menu silently fail.

I added a patch that ensures that these errors get written to watchdog by truncating the original query.
Once you see this error in the log it's easy to fix the issue by increasing "max_allowed_packet" within MySQL.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Bug because not being able to log an error that in consequence makes all other database queries fail and hence a fatal error is a bug.
Issue priority Major because MySQL server has gone away is a very generic error that does not help much.
Prioritized changes The main goal of this issue is to fix a bug and improve site user experience when large packets are encountered.
Disruption Not disruptive, neither for core nor contrib modules.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jpcwebb’s picture

Once you see this error in the log it's easy to fix the issue by increasing "max_allowed_packet" within MySQL. - yeah, for everyone not on shared hosting! What about a fix for the database system to work within the limitations of the system by, I dunno, maybe using multiple database entries or chunking for instance? Increasing "max_allowed_packet" is not a solution for many people.

mkalkbrenner’s picture

@jpcwebb:

What about a fix for the database system to work within the limitations of the system by, I dunno, maybe using multiple database entries or chunking for instance?

This is possible for dedicated tables like watchdog. But it's impossible as a generic solution for all tables or fields.
For watchdog it's what I did in my patch.

mkalkbrenner’s picture

Just a new attachment for the test bot.

mkalkbrenner’s picture

Version: 6.x-dev » 7.x-dev
Priority: Major » Critical
Status: Needs review » Patch (to be ported)
mkalkbrenner’s picture

Title: MySQL silently fails: Got a packet bigger than "max_allowed_packet" bytes » MySQL silently fails: Got a packet bigger than "max_allowed_packet" bytes / General error: 2006 MySQL server has gone away

On thing I forgot to mention. My patch in #3 depends on #298768: Ensure that entries are written to watchdog table

Everett Zufelt’s picture

Version: 7.x-dev » 8.x-dev
Priority: Critical » Major
Status: Patch (to be ported) » Needs work

Issues are resolved against 8.x, and then considered for backport to earlier versions. Can you please re-roll against 8.x?

Moving to priority Major, please see issue priority descriptions.

mkalkbrenner’s picture

Version: 8.x-dev » 7.x-dev
Priority: Major » Critical

see http://drupal.org/node/45111

Critical bugs either render a system unusable (not being able to create content or upgrade between versions, blocks not displaying, and the like)

If you read the contrib issues you'll see that the conditions for critical are met:

  1. The sites remains in a unusable state after enabling modules:
  2. The sites remains in a unusable state after clearing the caches or rebuilding the menu. That's really a bad user experience:

The solution the developer community offers is always the same:
closed (cannot reproduce)

It's a fault in your MySQL setup!

p.e. see
#1332008: content type page exploded in uncaught exception

So, from my point of view, two things need to happen:
1. Apply my patches to Drupal 6 and 7 to stop users blaming contrib module developers for errors they don't cause.
2. Write a patch for Drupal 8 to not create such big queries when rebuilding caches, menus, ... and backport this to at least Drupal 7.

Damien Tournoud’s picture

Version: 7.x-dev » 8.x-dev
Priority: Critical » Major
Status: Needs work » Patch (to be ported)

As explained, issues are resolved against 8.x, and then considered for backport to earlier versions.

We do have mitigation in place (for the theme registry and the field info cache), and the recommended value for max_allowed_packet is documented on the Requirements page, so this cannot possibly be considered a critical bug.

mkalkbrenner’s picture

Great to see that max_allowed_packet is now documented at the requirements page. I wasn't aware of this. But long time drupal developers won't read through this page too often ;-)

Nevertheless the fact of this issue remains and users and developers have a lot of trouble because Drupal simply doesn't tell them what's wrong.

Everett Zufelt’s picture

Status: Patch (to be ported) » Needs review

Status: Needs review » Needs work

The last submitted patch, mysql_packet_size_watchdog-972528.patch, failed testing.

Everett Zufelt’s picture

Status: Needs work » Needs review

I agree that the patch should go in, but it does need to be re-rolled so that it applies against 8.x. I would be in favor of it being backported as well.

catch’s picture

Status: Needs review » Needs work
Issue tags: +Needs backport to D6, +Needs backport to D7

Tagging. Also needs work - patch is going to be significantly different in 7.x and 8.x compared to 6.

The field info cache isn't fixed yet but there's a patch that needs work, there is #1040790: _field_info_collate_fields() memory usage (and #1009596: _content_type_info() memory usage improvements for CCK). And there is #1261846: Document 1MB maximum size limit for cache_set() that tries to document the limitation.

If you're getting this with the menu system cache, please open a separate issue for that - would be good to investigate why the cache item is so large as well as fixing the error reporting here.

catch’s picture

Title: MySQL silently fails: Got a packet bigger than "max_allowed_packet" bytes / General error: 2006 MySQL server has gone away » dblog fails to log MAX_ALLOWED_PACKET errors because they're longer than MAX_ALLOWED_PACKET
Priority: Major » Normal

I'm going to bump this down to normal. Core ships with syslog, which doesn't have this limitation, and there are plenty of workarounds.

xjm’s picture

Issue tags: +Needs tests
+++ b/includes/database.mysql.incundefined
@@ -126,10 +126,21 @@
+      case 1153: //Got a packet bigger than "max_allowed_packet" bytes
+        // If the MySQL Server rejected the query because it's too big,
+        // writing the query to database watchdog will fail as well
+        // Truncate the query ...
+        $query = substr($query, 0, 100);
+        break;

+++ b/includes/database.mysqli.incundefined
@@ -125,10 +125,21 @@
+      case 1153: //Got a packet bigger than "max_allowed_packet" bytes
+        // If the MySQL Server rejected the query because it's too big,
+        // writing the query to database watchdog will fail as well.
+        // Truncate the query ...
+        $query = substr($query, 0, 100);
+        break;

Let's use constants here rather than magic numbers and make the comment a little more concise. Also, the path needs to be rerolled against 8.x. Edit: I guess this is against 6.x so it will be fairly different.

Finally, we can add a test for this.

kasperg’s picture

Status: Needs work » Needs review
FileSize
4.77 KB

Here is an attempt at a reroll for Drupal 8 and a test case.

Writing the test proved quite challenging as provoking the error in the first place is not that trivial.

As xjm pointed out the code is quite different for D8 but the test case should be fairly easy to backport to D7.

mkalkbrenner’s picture

@kasberg: Thanks for writing the test.

The patch and the test look good to me.

Damien Tournoud’s picture

Status: Needs review » Needs work

This strikes me as belonging to the dblog module, not the database layer.

mkalkbrenner’s picture

Component: database system » dblog.module
Status: Needs work » Needs review

@Damien Tournoud:
It took me a couple of minutes to understand what you're talking about. It would be helpfull if you explain you concerns more detailed.

My interpretation:
You think that the dblog.module should ensure that the logging does not fail.

But that would mean that the dblog.module has to deal with a MySQL specific exception. From my point of view the MySQL database driver is the better place for that.

I'm interested in the opinion of others. Therefore I move the issue.

ryan.gibson’s picture

Splitting the patch into test and fix.

ryan.gibson’s picture

Oops, sorry, here is the separate test and the test/fix combined.

mikeytown2’s picture

D6 Pressflow patch based off of #3 assuming #476048-16: MySQL transient error handling has already been applied.

danblack’s picture

Issue summary: View changes
danblack’s picture

if your up for it, a warning in the install core/includes/install.core.inc on the current value id this.

select @@max_allowed_packet;
| @@max_allowed_packet |
| 16777216 |

mikeytown2’s picture

Would we want to set `SET SESSION max_allowed_packet=33554432` (32MB) at the init_commands level similar to #1650930: Use READ COMMITTED by default for MySQL transactions ?

danblack’s picture

Would we want to set `SET SESSION max_allowed_packet=33554432` (32MB) at the init_commands level similar to #165093

Actually you can't - "The session value of this variable is read only."

mikeytown2’s picture

Looks like the default is only 4MB for 5.6. Increasing this globally if it is less than X is something to consider; warn about it on the status page might be a good idea.

danblack’s picture

> warn about it on the status page might be a good idea.

yep. And the install page.

jhedstrom’s picture

Status: Needs review » Needs work
Issue tags: -Needs tests +Needs re-roll
jhedstrom’s picture

Issue tags: -Needs re-roll +Needs reroll
jsobiecki’s picture

Assigned: Unassigned » jsobiecki

I'm working on re-roll.

jsobiecki’s picture

I prepared re-roll, but it still doesn't works for me. I receive following error during testing:

"An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /batch?id=18&op=do_nojs&op=do
StatusText: Internal Server Error
ResponseText: {"error":"A fatal error occurred: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT table_name FROM information_schema.tables WHERE  (table_schema = :db_condition_placeholder_0) AND (table_name LIKE :db_condition_placeholder_1 ESCAPE \u0027\\\\\u0027) ; Array\n(\n    [:db_condition_placeholder_0] =\u003E d8\n    [:db_condition_placeholder_1] =\u003E simpletest474091%\n)\n"}"

I'm not sure if it's problem of my local mysql setup, or if it's something more general. I'm adding patch here for verification (I think it still requires some more work).

jsobiecki’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 32: dblog_fails_to_log-972528-32.patch, failed testing.

jsobiecki’s picture

It also fails on qa.drupal.org, but in different way. I'll try to investigate it, but at the moment, I'm out of ideas at the moment.

haripalrao’s picture

Assigned: jsobiecki » haripalrao
Status: Needs work » Needs review
FileSize
2 MB

Changes done!!!

Status: Needs review » Needs work

The last submitted patch, 36: dblog-fails-to-log-972528-36.patch, failed testing.

sudheeshps’s picture

Assigned: haripalrao » sudheeshps
Issue tags: +#DCM2015
zaporylie’s picture

jsobiecki’s picture

Issue tags: +dcw05
jsobiecki’s picture

Assigned: sudheeshps » jsobiecki

Last uploaded patch is faulty because of massive permissions change. Re-bease should be easy. I'm working on this.

jsobiecki’s picture

Status: Needs work » Needs review
FileSize
1.7 KB

I fixed this patch.

jsobiecki’s picture

Assigned: jsobiecki » Unassigned
jhedstrom’s picture

Status: Needs review » Needs work
Issue tags: -Needs reroll

Patch in #43 is missing the test from #21.

jsobiecki’s picture

Status: Needs work » Needs review
FileSize
4.03 KB

Ops, my fault. I added tests from #21 to uploaded patch.

mkalkbrenner’s picture

Status: Needs review » Needs work
  1. +++ b/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php
    @@ -52,6 +60,24 @@ public function __construct(\PDO $connection, array $connection_options = array(
    +        $message = Unicode::substr($e->getMessage(), 0, Connection::MAX_ALLOWED_PACKET_MESSAGE_LENGTH);
    

    I don't think that this is correct.
    MAX_ALLOWED_PACKET_MESSAGE_LENGTH is a size in byte.
    Unicode::substr() counts a multibyte UTF-8 character as 1.
    I assume that the bug is not fixed this way if the message contains multibyte characters.

  2. +++ b/core/modules/system/lib/Drupal/system/Tests/Database/LargeQueryTest.php
    @@ -0,0 +1,55 @@
    +        $long_name = str_repeat('a', $max_allowed_packet);
    

    use multibyte characters here instead of 'a'.

The last submitted patch, 45: dblog_fails_to_log-972528-45.patch, failed testing.

Status: Needs work » Needs review
jsobiecki’s picture

@mkalkbrenner,

Yes, it has sense. Attached patch uses truncateBytes() static method, that should return string with valid size. Let's see, if testbot likes it. I also replaced 'a' sign, with one of national letter, which is multi-byte.

Status: Needs review » Needs work

The last submitted patch, 49: dblog_fails_to_log-972528-49.patch, failed testing.

mkalkbrenner’s picture

  1. +++ b/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php
    @@ -35,6 +36,14 @@ class Connection extends DatabaseConnection {
    +   * The maximum length of exception messages if a max_allowed_packet error
    +   * occurs.
    +   *
    +   * @var int
    +   */
    +  const MAX_ALLOWED_PACKET_MESSAGE_LENGTH = 1024;
    

    What about getting this value dynamically when the error occurs?
    If we keep the static value the comment should be enhanced and state that 1024 is the minimal value allowed within MySQL/MariaDB and add the link to https://mariadb.com/kb/en/mariadb/server-system-variables/#max_allowed_p...

  2. +++ b/core/modules/system/lib/Drupal/system/Tests/Database/LargeQueryTest.php
    @@ -0,0 +1,55 @@
    +      $result = db_query("SHOW VARIABLES WHERE Variable_name = 'max_allowed_packet'")->fetchCol(1);
    

    I think the recommended (and faster) way to retrieve this value is SELECT @@global.max_allowed_packet;

  3. +++ b/core/modules/system/lib/Drupal/system/Tests/Database/LargeQueryTest.php
    @@ -0,0 +1,55 @@
    +        } catch (DatabaseException $e) {
    +          $this->assertEqual(strlen($e->getMessage()), \Drupal\Core\Database\Driver\mysql\Connection::MAX_ALLOWED_PACKET_MESSAGE_LENGTH, "'max_allowed_packet' exception message truncated");
    +        }
    

    I think we should add another assertion to check for the error code 1153 again.

jsobiecki’s picture

I tried to find a good way to get way to dynamically determine value for maximum packet size, but haven't found any. So if you have some sort of suggestion how to do that, I'm open for suggestions :)

Two remaining comments make sense. I'll update patch, and update issue (probably today, or tomorrow).

mikeytown2’s picture

$results = db_query("SHOW VARIABLES LIKE 'max_allowed_packet'")->fetchAssoc();
echo $results['Value'];

(from APDQC)

jsobiecki’s picture

I wasn't too specific when I mentioned about way to determine max_packet_size variable. Query is quite obvious, but I see some problems.

- Where to execute such query, and how to avoid execution of query at each page request (maybe even more frequent). I thought about using CMI or caching, but I think it might fail at some scenarios.

I decided to leave it as is (and stay with static value). If it will work corretly, I can try to return to dynamic approach.

jsobiecki’s picture

Status: Needs work » Needs review
mkalkbrenner’s picture

Status: Needs review » Needs work

I didn't notice that before, but the tests aren't running at all due to these reasons:

  1. +++ b/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php
    --- /dev/null
    +++ b/core/modules/system/lib/Drupal/system/Tests/Database/LargeQueryTest.php
    

    This folder is not scanned for tests.

  2. +++ b/core/modules/system/lib/Drupal/system/Tests/Database/LargeQueryTest.php
    @@ -0,0 +1,56 @@
    +/**
    + * Tests handling of large queries.
    + */
    +class LargeQueryTest extends DatabaseTestBase {
    

    The required group annotation is missing.

  3. +++ b/core/modules/system/lib/Drupal/system/Tests/Database/LargeQueryTest.php
    @@ -0,0 +1,56 @@
    +      if (drupal_check_memory_limit($max_allowed_packet)) {
    

    This is a drupal 7 function that doesn't exist in drupal 8.

mkalkbrenner’s picture

Status: Needs work » Needs review
FileSize
5.45 KB

OK, here's a patch including a test that "should" work now.
But as I already mentioned in #5 three years ago, it will require #298768: Ensure that entries are written to watchdog table to be committed first. The reason is that an error "1153" causes "2006 MySQL server had gone away" for all further queries.

Status: Needs review » Needs work

The last submitted patch, 58: 972528_58.patch, failed testing.

mkalkbrenner’s picture

Status: Needs work » Needs review
FileSize
7.09 KB

So here is a working patch now. But this one already includes #298768: Ensure that entries are written to watchdog table to get results from the test bot.

jsobiecki’s picture

+++ b/core/modules/system/src/Tests/Database/LargeQueryTest.php
@@ -0,0 +1,67 @@
+      if (\Drupal\Component\Utility\Environment::checkMemoryLimit($max_allowed_packet + (16 * 1024 * 1024))) {

It's minor thing, but I think it might be better to add use statement at begining of file, and refactor this to Environment::checkMemoryLimit()

Status: Needs review » Needs work

The last submitted patch, 60: 972528_60_including_298768.patch, failed testing.

mikeytown2’s picture

@harijari
Run the query on cron, save to a variable if it's been changed. I would also opt to run the query on install and have a update function for sites that are already in use as 1024 is really small. If dblog fails due to packet size, re-run the query and update the variable on the spot.

mkalkbrenner’s picture

Run the query on cron, save to a variable if it's been changed. I would also opt to run the query on install and have a update function for sites that are already in use as 1024 is really small. If dblog fails due to packet size, re-run the query and update the variable on the spot.

I think that's too much overhead for an error that should only occur once in a setup or if the setup changed.
1024 bytes are enough to express the problem completely.

mkalkbrenner’s picture

Status: Needs work » Needs review
FileSize
5.11 KB
7.38 KB

The "current final" patch for this issue is 972528_65-do-not-test.patch.
For the testbot I attached 972528_65_including_298768.patch that contains the fix from https://www.drupal.org/node/298768#comment-10011327

mkalkbrenner’s picture

Just some minor fixes:

jsobiecki’s picture

From perspective of person, who is quite new to D8, patch looks OK. Patch applies cleanly, phpunit tests are all green and test-bot is also happy.

I'm wondering on few minor things:

+++ b/core/modules/dblog/src/Logger/DbLog.php
@@ -44,8 +50,8 @@ class DbLog implements LoggerInterface {
-  public function __construct(Connection $database, LogMessageParserInterface $parser) {

Why variable name was changed?

+      if (
+        ($e instanceof DatabaseException || $e instanceof \PDOException) &&
+        $this->connection->getTarget() != self::DEDICATED_DBLOG_CONNECTION_TARGET
+      ) {

I'm not sure, but maybe we should also check here for error codes (from second side, it's to much mysql-ish).

mkalkbrenner’s picture

Status: Needs review » Reviewed & tested by the community

Why variable name was changed?

Because the previous name was wrong. And now as both classes, Database and Connection are used here, it was time to rename the variable correctly. Otherwise the code will look confusing.

I'm not sure, but maybe we should also check here for error codes (from second side, it's to much mysql-ish).

You answered it by yourself. The error codes of the examples within the comments are specific to MySQL - probably the most common database for Drupal. But Dblog works with all database drivers available for drupal. And even for different databases it makes sense to retry the write once using a new connection if a database exception is thrown during the write of a log entry.

Both comments are targeting parts of the patch that are embedded from #298768: Ensure that entries are written to watchdog table. This one is required to satisfy the testbot here until the other issue is committed to core.

The patch you need to review here is 972528_66-do-not-test.patch.

I know that this is somehow confusing.

mkalkbrenner’s picture

Status: Reviewed & tested by the community » Needs review

Sorry. as I posted the last comment I thought I'm in #298768: Ensure that entries are written to watchdog table. Back to "Needs review". And I edited the post above.

hchonov’s picture

Shortening the message so early would mean that all the loggers will receive the incomplete message to log, even SysLog which does not introduce such a problem as DbLog as also indicated by @catch in #14.

What about a solution, where we add to the Exception the details about the Database driver and the error code.
When a Database Logger gets also an Exception on writting the log then it will compare the error codes and if they are the same, then call a best effort method write against the connection which then based on the error code should shorten the message if neccessary. And in the MySql connection I would shorten each of the fields to the max allowed packet size.

It is a more complicated solution but it allows for further improvements and database error handling.

Or something else which should be faster to implement. To the exception we introduce a second variable message_for_db and there we store the shortened message, then in DbLog before calling parseMessagePlaceholders we exchange the context['message'] with context['message_for_db']. This way SysLog will store the complete message and DbLog only the message which should not cause the same database exception on writting again.

mkalkbrenner’s picture

Shortening the message so early would mean that all the loggers will receive the incomplete message to log, even SysLog which does not introduce such a problem as DbLog

Theoretical your right.

But we're dealing with an edge case here which should not occur very often or regulary in a production environment.
Therefor we should keep the code as simple as possible. And 1024 characters are 1KB of data. That should be enough for a single log entry. Again, once the error is fixed, the log entry won't occur anymore.

The most important point here is that (initially) something is in the log! Normally you don't have to search for bugs in the code but in the MySQL setup. Therefor the error code 2006 is enough information.

Nevertheless we can discuss here how the log message is shorten best.
Maybe we should compose it of the first x characters of the MySQL error message that repeats the query and the amount of KB that was tried to send to MySQL. This number doesn't have to be exact and can roughly be calculated from the original error message.

mkalkbrenner’s picture

FileSize
4.81 KB

#298768: Ensure that entries are written to watchdog table is committed now :-)

Therfore I upload the unmodified 972528_66-do-not-test.patch again named 972528_72.patch to get it tested.

Fabianx’s picture

Status: Needs review » Reviewed & tested by the community

RTBC, looks great

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php
@@ -35,6 +36,16 @@ class Connection extends DatabaseConnection {
   /**
+   * The minimal possible value for the max_allowed_packet setting of MySQL.
+   *
+   * @link https://mariadb.com/kb/en/mariadb/server-system-variables/#max_allowed_packet
+   * @link https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_max_allowed_packet
+   *
+   * @var int
+   */
+  const MIN_MAX_ALLOWED_PACKET = 1024;

Can we not add something to mysql's Drupal\Core\Database\Driver\mysql\Install\Tasks to test this prior to installation?

mkalkbrenner’s picture

Status: Needs work » Needs review

Can we not add something to mysql's Drupal\Core\Database\Driver\mysql\Install\Tasks to test this prior to installation?

@alexpott: yes, we can do that in addition. But I think there are common use-cases like moving an installation from one hoster to another or to upgrade the OS or packages that might change the MySQL configurations. In these cases we have to select a safe value that ensures that the truncated message is logged.

That said, I wonder if it's worth to add some additional code to maximize the log message. I'm still of the opinion that the first characters of the log message are enough to solve the issue like I explained in #71:

The most important point here is that (initially) something is in the log! Normally you don't have to search for bugs in the code but in the MySQL setup. Therefor the error code 2006 itself is enough information.

Fabianx’s picture

+++ b/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php
@@ -52,6 +63,24 @@ public function __construct(\PDO $connection, array $connection_options = array(
+        $message = Unicode::truncateBytes($e->getMessage(), self::MIN_MAX_ALLOWED_PACKET);
+        $e = new DatabaseExceptionWrapper($message, $e->getCode(), $e->getPrevious());

Can we prepend a more descriptive message here to $message - even if it means shortening some more.

I would happily trade some more bytes to searching google for "mysql 2006" to get a descriptive error message of what happened and what I can do about it and how I can debug it.

mkalkbrenner’s picture

There is an official recommendation on https://www.drupal.org/requirements/database to set max_allowed_packet to at least 16M. As far as I know this recommendation comes form drupal 7. Does anybody know if that changed for drupal 8?

BTW I erroneously mentioned the error code 2006 as the important information that has to logged. The important code that will be logged is 1153!

mkalkbrenner’s picture

The log message currently starts with

SQLSTATE[08S01]: Communication link failure: 1153 Got a packet bigger than 'max_allowed_packet' bytes:

and continues with the SQL statement until it is truncated.

@FabianX: What's your suggestion? What kind of information should be added to this string? Should we explain that error an add a link to the drupal documentation on https://www.drupal.org/requirements/database ?

Fabianx’s picture

Assigned: Unassigned » alexpott
Issue tags: +Needs framework manager review

#78: @Fabianx please, lowercase x.

Yes, I think linking to the handbook page would be great user service.

Alex Pott - Thoughts?

Edit: Added the framework manager tag as I think linking to handbook pages from error messages is not yet done in core, but not totally sure ...

alexpott’s picture

I don't think we should be linking to the handbook. The handbook page should contain the error message so if someone searches d.o for it they find it. It would be the only example in core of doing this.

mkalkbrenner’s picture

Status: Needs review » Reviewed & tested by the community

Due to the last comment of @alexpott in #80 I set this back to RTBC as in #73.
The concern in #74 was addressed in #75.

xjm’s picture

Assigned: alexpott » Unassigned
Status: Reviewed & tested by the community » Needs review

For what it's worth, we do link to handbook pages both in error messages and in the codebase, so I disagree with #80 and am not sure why @alexpott says there are no other examples of this. I also don't see why that's a framework manager decision; seems more about the product and documentation to me.

xjm’s picture

Status: Needs review » Reviewed & tested by the community

Not worth blocking the patch on I guess; could be a followup.

Fabianx’s picture

Priority: Normal » Major
Issue summary: View changes

I just ran into that again on travis-ci.

Increasing priority to major, because this one is really hard to find without a proper error message.

Added beta evaluation.

alexpott’s picture

Version: 8.0.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Committed 543ee3c and pushed to 8.0.x. Thanks!

diff --git a/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php b/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php
index 0f29946..4bc3c29 100644
--- a/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php
+++ b/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php
@@ -69,7 +69,7 @@ public function query($query, array $args = array(), $options = array()) {
     } catch (DatabaseException $e) {
       if ($e->getPrevious()->errorInfo[1] == 1153) {
         // If a max_allowed_packet error occurs the message length is truncated.
-        // This should prevent the error from reoccuring if the exception is
+        // This should prevent the error from recurring if the exception is
         // logged to the database using dblog or the like.
         $message = Unicode::truncateBytes($e->getMessage(), self::MIN_MAX_ALLOWED_PACKET);
         $e = new DatabaseExceptionWrapper($message, $e->getCode(), $e->getPrevious());
diff --git a/core/modules/system/src/Tests/Database/LargeQueryTest.php b/core/modules/system/src/Tests/Database/LargeQueryTest.php
index 790b72c..eed8004 100644
--- a/core/modules/system/src/Tests/Database/LargeQueryTest.php
+++ b/core/modules/system/src/Tests/Database/LargeQueryTest.php
@@ -47,7 +47,7 @@ function testMaxAllowedPacketQueryTruncating() {
         }
       }
       else {
-        $this->verbose('The configured max_allowed_package exceeds the php memory limit. Therefore the test is skipped.');
+        $this->verbose('The configured max_allowed_packet exceeds the php memory limit. Therefore the test is skipped.');
       }
     }
     else {

Fixed on commit.

  • alexpott committed 543ee3c on 8.0.x
    Issue #972528 by mkalkbrenner, harijari, ryanissamson, mikeytown2,...

  • alexpott committed 543ee3c on 8.1.x
    Issue #972528 by mkalkbrenner, harijari, ryanissamson, mikeytown2,...

  • alexpott committed 543ee3c on 8.3.x
    Issue #972528 by mkalkbrenner, harijari, ryanissamson, mikeytown2,...

  • alexpott committed 543ee3c on 8.3.x
    Issue #972528 by mkalkbrenner, harijari, ryanissamson, mikeytown2,...

  • alexpott committed 543ee3c on 8.4.x
    Issue #972528 by mkalkbrenner, harijari, ryanissamson, mikeytown2,...

  • alexpott committed 543ee3c on 8.4.x
    Issue #972528 by mkalkbrenner, harijari, ryanissamson, mikeytown2,...