action #55541
closed
from o3: DBIx::Class::Storage::DBI::select_single(): Query returned more than one row. SQL that returns multiple rows is DEPRECATED for ->find and ->single at /usr/share/openqa/script/../lib/OpenQA/WebAPI/Controller/Running.pm line 64
Added by okurz over 5 years ago.
Updated about 5 years ago.
Category:
Regressions/Crashes
Description
Observation¶
DBIx::Class::Storage::DBI::select_single(): Query returned more than one row. SQL that returns multiple rows is DEPRECATED for ->find and ->single at /usr/share/openqa/script/../lib/OpenQA/WebAPI/Controller/Running.pm line 64
- Priority changed from Normal to High
- Target version set to Ready
there are 2 places that fill the log:
Aug 30 14:00:34 openqa openqa[9008]: DBIx::Class::Storage::DBI::select_single(): Query returned more than one row. SQL that returns multiple rows is DEPRECATED for ->find and ->single at /usr/share/openqa/script/../lib/OpenQA/WebAPI/Controller/Running.pm line 64
Aug 30 18:09:02 openqa openqa[9008]: DBIx::Class::Storage::DBI::select_single(): Query returned more than one row. SQL that returns multiple rows is DEPRECATED for ->find and ->single at /usr/share/openqa/script/../lib/OpenQA/Schema/Result/Workers.pm line 177
- Assignee set to Xiaojing_liu
- Target version changed from Ready to Current Sprint
I checked the logs in my test environment, there are the same logs in journalctl -a
. And I checked the jobs that run at the same time, found nothing abnormal. I tried to reproduce this ticket and add log in code, but failed to reproduce it.
I searched the log message in google. Someone suggest adding 'key => ' in the search condition. I think I should find out why the find
returns more than one result about 'running job module'. There should be only one at the same time.
If you have any suggestion, please tell me. I really appreciate it. If my way is wrong, feel free let me know.
The error message says exactly which the problematic line is, e.g. in Workers.pm
the find
call in that function:
sub currentstep {
my ($self) = @_;
return unless ($self->job);
my $r = $self->job->modules->find({result => 'running'});
$r->name if $r;
}
So this is actually connected to timing issues of the worker upload which apparently also leads to more than one module being "running" at the same time. Maybe you can just replace $self->job->modules->find({result => 'running'})
with $self->job->modules->search({result => 'running'})->last
. This would simply ignore modules stuck in "running" and only consider the last running module (which is likely the only truly running module).
If you really want to reproduce the problem the easiest way to do it would be in a unit test. But I don't think this is actually necessary here (it might be for the occurrence in Running.pm
which I haven't looked into).
Likely it is not as easy as using $self->job->modules->search({result => 'running'})->last
because the order might be arbitrary. I suppose $self->job->modules->find({result => 'running'}, {rows => 1, order_by => {-desc => 't_updated'}})
should work better.
mkittler wrote:
Likely it is not as easy as using $self->job->modules->search({result => 'running'})->last
because the order might be arbitrary. I suppose $self->job->modules->find({result => 'running'}, {rows => 1, order_by => {-desc => 't_updated'}})
should work better.
Thanks very much. I tested it, it works well.
- Status changed from New to Feedback
- Status changed from Feedback to Resolved
- Target version changed from Current Sprint to Done
I guess we can consider it done and re-open if the fix didn't work (which is unlikely).
Also available in: Atom
PDF