Fixed parameters borked as soon as code was going through another sql(?) #1686
Conversation
LINE 11: target_version=$1,<br />
^<br />
DETAIL: integer gegen character varying for the query: UPDATE mantis_bug_table<br />
SET project_id=$1, reporter_id=$2,<br />
handler_id=$3, duplicate_id=$4,<br />
priority=$5, severity=$6,<br />
reproducibility=$7, status=$8,<br />
resolution=$9, projection=$10,<br />
category_id=$11, eta=$12,<br />
os=$13, os_build=$14,<br />
platform=$15, version=$16,<br />
build=$17, fixed_in_version=$18,<br />
target_version=$1,<br />
view_state=$2,<br />
summary=$3,<br />
sponsorship_total=$4,<br />
sticky=$5,<br />
due_date=$6<br />
WHERE id=$7.</p>
|
@FrankyB Thanks for your contribution. Please note that issues should be reported at https://mantisbt.org/bugs, GitHub PR's are only to submit a patch, which should reference an existing issue. That being said, I'm afraid that your PR is only addressing the symptoms and not the root cause of the problem; unfortunately you are not giving sufficient information to reproduce the problem, and it is not clear whether it is caused by MantisBT core, by the Source Integration plugin (I assume that's what you mean by plugins/Source, and by the way you did not specify which VCS plugin you're using); for the record we have been running that without issues for many years. Please provide version information, plugins used and detailed steps to reproduce. A stack trace just before the point where the param count gets reset would be helpful as well. |
|
@FrankyB please provide also information about the database you use. |
|
-- edit: sorry, will be off-work for the next two weeks. coming back the 17th of August, then I will create a elaborated bug report -- @dregad: Please tell me how do I create a stack trace at that point |
That depends on the tools you're using, e.g. with PHPStorm you can step through the code in debug mode and copy the stack trace. More bare-bones, you could add |
|
Follow-up and discuss in https://mantisbt.org/bugs/view.php?id=27113 |
|
Closing this, as I'm pretty sure now that the problem is with Source Integration plugin |
Hi!
See this error message when having target versions & trying to resolve an issue via plugins/Source.
If you like to see, the parameter numbering goes up to 18, then another db action interrupts(uh, thats what I think, at least), and the parameter numbering starts from $1 again (at target_version).
I simply store the condition in a local variable and therefore have no need to restart db_param()
I am not sure if this is a good fix acording to your overall coding. Maybe I can also store db_param() somewhere, do another DB operation and pop it afterwards.
It would be good to have this fixed, it was at least disturbing plugins/Source.
Thank you,
Frank
LINE 11: target_version=$1,
^
DETAIL: integer gegen character varying for the query: UPDATE mantis_bug_table
SET project_id=$1, reporter_id=$2,
handler_id=$3, duplicate_id=$4,
priority=$5, severity=$6,
reproducibility=$7, status=$8,
resolution=$9, projection=$10,
category_id=$11, eta=$12,
os=$13, os_build=$14,
platform=$15, version=$16,
build=$17, fixed_in_version=$18,
target_version=$1,
view_state=$2,
summary=$3,
sponsorship_total=$4,
sticky=$5,
due_date=$6
WHERE id=$7.