action #55541
closedfrom 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
0%
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
Updated by coolo over 5 years ago
- 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
Updated by Xiaojing_liu over 5 years ago
- Assignee set to Xiaojing_liu
- Target version changed from Ready to Current Sprint
Updated by Xiaojing_liu over 5 years ago
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.
Updated by mkittler over 5 years ago
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).
Updated by mkittler over 5 years ago
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.
Updated by Xiaojing_liu over 5 years ago
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.
Updated by Xiaojing_liu over 5 years ago
Updated by mkittler about 5 years ago
- 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).