View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0035247 | mantisbt | public | 2025-01-18 16:39 | 2025-02-01 10:19 | |
Reporter | dregad | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | confirmed | Resolution | open | ||
Summary | 0035247: Data too long for column 'body' when adding a note to an Issue | ||||
Description | When adding a bugnote to issue 0012830, MantisBT throws APPLICATION ERROR 401 | ||||
Tags | No tags attached. | ||||
related to | 0012830 | new | new HTMLMail plugin v0.1 |
That error is strange, because the body column is defined as ADOdb XL metatype in the database schema; for MySQL, this gets converted to LONGTEXT, which can store 4'294'967'296 bytes [1]. |
|
Looks like the DB schema on this tracker's is not in sync with what the installer generates: mantisbt.org
fresh install 2.27.1
body and metadata columns are defined as TEXT (65'536 bytes) instead of LONGTEXT. |
|
The discrepancy comes from an old commit from 2007 MantisBT master 55384a2f that changed the column type from XS to XL. As far as I know, XS is not a standard ADOdb metatype (but maybe it was back in 2007 ?) I guess that change was never applied to the mantisbt.org bugtracker's schema... We should probably fix that. That being said, in my opinion it makes absolutely no sense to include the whole list of bugnotes in a notification email as nobody would read the whole lot (in this specific case, that's 78 bugnotes as of this writing, and each notification mail if it got sent, would be over 70 KB). We should limit the number of bugnotes to a reasonable number (e.g. the most recent 10). |
|
@atrol following up on your note 0012830:0069724
The problem is that the default value will be stored in user preferences, so changing the value in config_inc.php is not sufficient to prevent the error from occurring when adding a note to 0012830.
If we don't alter the DB schema to align it with how it's currently generated by the installer, we would need to update all the 17323 zeros, plus the 90 and 99 (in reality, anyone having more than 0000040:0000070). As mentioned in my earlier post, I think we should enforce a maximum value for this setting, i.e. prevent users from setting a value too high. This means either an arbitrary, hardcoded number (10 ? 20 ?) or introduce a new config. The latter would be better IMO. |
|
@dregad my intention when adding this note was just to prevent that Cas introduces a redundant option. The approach to limit by numbers of notes is not resolving the database storage issue in a clean way.
We do (limit to two digits), but there is setting 0 (unlimited) that must just be checked if user has enabled "E-mail Full Issue Details" (somehow redundant, it might have been better if we had used setting 0 (unlimited) for that |
|
Correct, it's not a 100% safe approach but with a reasonably small(er) maximum number of notes, the risk of encountering the error is greatly reduced.
True, but considering the way the mails are generated, it's not so straightforward to do in a clean way.
Bottomline is, our DB is wrong and we need to fix it. Probably not worth the effort to make code adaptations to fit email body to 65KB. |
|
@dregad fixing our DB should be enough, no code changes needed.
Couldn't we do it in a similar way like we do it for history values?
[EDIT] certainly not that good in terms of performance and memory usage if this would be done at one single place before inserting to the table |
|
Removing target version, as this is not caused by MantisBT code, but due to specifics of the mantisbt.org database. |
|