Join 34,000+ subscribers and receive articles from our
blog about software quality, testing, QA and security.

"An error occurred during the last operation. Please try again ... "


#1

Dear Forum,

I have been struggling with the display bug where when trying to preview the results for a run, I get the following error


I noticed that it is a preview that gets broken for some reason. By trial & error, I figured that it seems to be related with the size of the ‘actual’ step result. Below 1500 characters, all seems to work fine. Anything above that, I get this error and no way to make it go away. I already increased PHP memory pool to 512MB (no charge), increased memory allocation in MySQL DB (maxed out everything I could access) and still no game.

Is there any hard limit on the number of characters that go into the ‘actual’ result field?

I also verified DB structure to make sure it is not corrupts and does not contain any illegal characters that might be messing with the parsers. Nothing stands out. Below is the structure of the field as retrieved from DB:

=========================

Given the size, I had to put it up on GoogleDocs

=========================

Thanks

M


#2

I think the assumption is correct based on your findings. I have been looking thru our tables to see if I can find the field the Expected details are - I think that is the field in question. I wanted to see the definition of the field but not have had any luck. There is a Content_Id but can’t find the corresponding table for it.

For Expected Result - I would do an attachment. We try and keep the Results data to be as small and compact as possible. Once it starts getting large I find those types of things get hard to follow.


#3

Thanks for the answer.

Since the API does not support attachments at this time, the whole point was to load all data into the ‘actual’ field and let the system handle it. I have way too many test cases and result runs to do this by hand, hence my attempt to push data from execution system directly into Testrail for reporting (since it is “pretty” :)).

What is more, I found that the same data works fine on the demonstration Testrail instance (@testrail.io) but no matter I do on my local MySQL database, it does not want to take it.

That points to DB structure difference … any clues what to look for?

Thanks

M


#4

I copied and pasted the GoogleDoc in one of my test cases in our test instance with MS SQL and had no issues.

So at this point I would look to MySQL and think it is a limitation of MySQL db. Be nicer if I could find the field and then you could look at the field definition.

I would email the Gurock support group with a link to this thread and ask them to verify the limitation with MySQL.


#5

As far as I can tell, the field is defined as LONGTEXT so it should be able to handle 4GB data without any hiccups. However, I suspect that it is the interaction between Testrail and DB that is failing for some reason. I traced the behavior to the loader module, which is unfortunately a compiled binary so my debugging ends there for the time being. It seems like it can read data off database, but fails on parsing / processing it for some reason.

I attempted to enable debug under Testrail but the level of detail is way insufficient to observe what is really going on and where the problem lies.


#6

Here is the snippet from MySQLAdmin for reference - all looks solid in there, just one big happy longtext-type field