757: 1153, "Got a packet bigger than 'max_allowed_packet' bytes"
- Incomplete
- Review Board
ajaykr******@gmai***** (Google Code) (Is this you? Claim this profile.) | |
Feb. 10, 2009 |
What's the URL of the page containing the problem? When i update diff What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? What operating system are you using? What browser? Please provide any additional information below.
Closing out, because the needed information was not provided. If you can provide this info, please add a comment and we'll reopen the bug.
-
- NeedInfo + Incomplete
I was able to reproduce this issue by submitting a diff that was larger than mysql's max_allowed_packet size. from post-review: >>> Review request created >>> Uploading diff, size: 1593200 >>> HTTP POSTing to http://reviews/api/json/reviewrequests/13/diff/new/: {} Error uploading diff: One or more fields had errors (105) >>> {u'fields': {u'path': [u'(1153, "Got a packet bigger than \'max_allowed_packet\' bytes")']}, u'stat': u'fail', u'err': {u'msg': u'One or more fields had errors', u'code': 105}} Your review request still exists, but the diff is not attached. mysql> show variables like "max_allowed_packet"; +--------------------+---------+ | Variable_name | Value | +--------------------+---------+ | max_allowed_packet | 1048576 | +--------------------+---------+ 1 row in set (0.00 sec) Note the diff size 1593200 vs the max_allowed_packet default size 1048576 http://dev.mysql.com/doc/refman/5.1/en/packet-too-large.html suggests that it needs to be a co- ordinated change on both the client- and server-side.
Diffs that huge are unreviewable anyway, and probably binary, so there's not really a good reason to store them in the DB. Here's a quick patch to skip over them.
-
+