Page 1 of 1

data type mismatch error

Posted: 31 May 2018, 16:03
by mushu
MantisBT Version 2.7.0
PHP Version 5.6.24
MantisBT Database Information
Schema Version 209
ADOdb Version 5.20.9


Unknowingly, two people in the same ticket, one a developer the other an administrator, the developer closes the ticket while at almost exactly the same time the admin changed the status and owner. Admin got this error message. Thinking this race condition could be mitigated by either using strict locking in mysql instead of opportunistic? Or adding code to "critical" actions such as status change that does a quick check to see if the ticket is still in a state the current instance thinks it is. If that made any sense...
error screen
error screen
Mantis error.png (45.01 KiB) Viewed 3356 times

Re: data type mismatch error

Posted: 01 Jun 2018, 17:19
by mushu
No thoughts from anyone? Wondering if there were any code changes since then that would prevent this kind of error in the current version?

Re: data type mismatch error

Posted: 11 Jun 2018, 16:59
by mushu
(MOSTLY) RESOLVED IN LATEST VERSION 2.15.0

The latest version has changed the error message to actually include useful information (to wit: this issue has been modified by another user....) Compare this current error message to previous screenshot in original post.
screenshot-agrapoly01-8888-2018.06.11-09-55-57.png
screenshot-agrapoly01-8888-2018.06.11-09-55-57.png (27.81 KiB) Viewed 3291 times

Re: data type mismatch error

Posted: 11 Jun 2018, 17:42
by atrol
mushu wrote: 11 Jun 2018, 16:59 (MOSTLY) RESOLVED IN LATEST VERSION 2.15.0
The latest version has changed the error message to actually include useful information
A bit strange as this message has been introduced in 2014 so I would have expected that you got it also when using version 2.7.0.
https://www.mantisbt.org/bugs/view.php?id=5466
https://github.com/mantisbt/mantisbt/co ... 218b3cbe17

Seems there was one more issue ...

Re: data type mismatch error

Posted: 11 Jun 2018, 17:49
by mushu
Ugh. That means we were unable to duplicate the original problem, and it likely is still an issue. Guessing some kind of typical race condition in the code caused by not atomically verifying that the ticket to be processed is in the same state as when it was read into memory. So maybe don't resolve just yet...