Service Catalog Items report stuck in Generating Report when Service fields included

[jbarson47]

We are seeing issues in Najdorf with a more complex report run from our master replication region where it gets stuck in "Generating Report" - the play icon changes to a different symbol and the report never gets actually generated. When removing some fields from the report, it does eventually update and load after some time, making me think the report may be timing out due to the time it takes to gather the needed info.

Specifically, the report based on Service Catalog Items runs in a normal amount of time when only direct attributes and associated Request attrs are selected in the report. However, when adding a Service attribute, such as Date Created in this case (image below), the report fails each time and appears to be timing out as described above.

I would also add that from the tasks view, these "hung" reports still have a running status until eventually showing as complete with "Saved Report "2023-08-15 16:55:52 UTC" not found, Schedule may have failed" when attempting to view.

Could I get some guidance on why this is the case, and how the timeout limits can be adjusted if this is indeed simply a timeout issue? No actual errors appear in evm or automation log files that we can identify, things simply seem to hang up generating.

[Fryguy]

@jbarson47 Can you provide an export of the report in question? This may have been recently fixed with some report prioritization fixes that recently landed (#22563)

[kbrock]

@jbarson47 I am not sure how many services you have defined, but adding in a service column greatly increases the number of rows for my local database. It brings back every service that is used by each of the service templates.

You may want to try starting with a Services. From there you should be able to add the service template.

developer notes

• service catalog items base report: manageiq-ui-classic/product/views/ServiceCatalog.yaml
• base model: ServiceTemplate
• "Requests" is definitely has_many :miq_requests (a reverse polymorphic association)
• "Services" is probably has_many :services (not defined in en.yml), but possibly container_services or host_services
• services.created_at is a sql attribute. the attribute is super quick

[jbarson47]

Thanks @Fryguy @kbrock . When we add in the service column to the report, generation times out with nothing to export. In the meantime we've gone a different route by just utilizing the Requests : Date Created instead which is much smaller as @kbrock alluded to. Will try out the above suggestion and see if we're able to successfully run the original report.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.