balrog should raise an error when data will be truncated

RESOLVED WONTFIX

Status

Release Engineering
Balrog: Backend
P5
normal
RESOLVED WONTFIX
6 years ago
7 months ago

People

(Reporter: bhearsum, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
bug 701865 describes a situation where we had data silently truncated by MySQL. We worked around it by using a larger field, but it's still possible for large enough data to be truncated. Balrog should throw an error when data will be truncated rather than letting it happen silently.

MySQL has a 'show warnings' command that can supposedly tell you when these sort of things happen, but we may be better off using our own method. Doing so would let us test it much better/more easily, and remain DB-agnostic.
(Reporter)

Comment 1

6 years ago
10:56 < catlee> so you may be able to configure the warnings module to raise the warning as an exception
10:56 < catlee> but you still need to call cursor.info()
10:57 < catlee> so maybe assert connection.warning_count() == 0 is ok
found in triage.
Component: Release Engineering → Release Engineering: Automation
QA Contact: release → catlee
(Reporter)

Comment 3

6 years ago
We hit this again with Releases.version, bug 748399.
(Reporter)

Updated

6 years ago
Blocks: 791074
No longer blocks: 583244
(Reporter)

Updated

6 years ago
Blocks: 583244
No longer blocks: 791074
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering
(Reporter)

Comment 4

4 years ago
mass component change
Component: General Automation → Balrog: Backend

Updated

3 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3403]

Updated

3 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3403] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3408]

Updated

3 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3408] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3410]
(Reporter)

Comment 5

3 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #1)
> 10:56 < catlee> so you may be able to configure the warnings module to raise
> the warning as an exception
> 10:56 < catlee> but you still need to call cursor.info()
> 10:57 < catlee> so maybe assert connection.warning_count() == 0 is ok

Another option might be to enable strict mode, which will cause the queries to fail.
(Reporter)

Comment 6

3 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #5)
> (In reply to Ben Hearsum [:bhearsum] from comment #1)
> > 10:56 < catlee> so you may be able to configure the warnings module to raise
> > the warning as an exception
> > 10:56 < catlee> but you still need to call cursor.info()
> > 10:57 < catlee> so maybe assert connection.warning_count() == 0 is ok
> 
> Another option might be to enable strict mode, which will cause the queries
> to fail.

https://github.com/mozilla/balrog/commit/d15f6cdfa23665c91021ff4b27e60a69e6b4b065 did this for the db upgrade script and it seemed to work well. We should try enabling it for the admin app and see how the errors manifest themselves. Eg, do we need to make any additional changes to get useful error messages.
(Reporter)

Updated

a year ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3410]
(Reporter)

Comment 7

7 months ago
We haven't hit this since switching the releases.data column to LONGTEXT. I doubt this is worth fixing.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Priority: P3 → P5
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.