Unusual query timing results with aggregator connection with caching enabled when some connections have errors

[cbruno10]

Describe the bug
When I query an aggregator with caching enabled, and I encounter errors, e.g.,

aws_pipeling_012: table 'aws_s3_bucket' column 'region' requires hydrate data from getBucketLocation, which failed with error operation error S3: GetBucketLocation, exceeded maximum number of attempts, 9, https response error StatusCode: 0, RequestID: , HostID: , request send failed, Get "https://stackset-test-bucket.s3.us-east-1.amazonaws.com/?location=": lookup stackset-test-bucket.s3.us-east-1.amazonaws.com on 192.168.1.1:53: read udp 192.168.1.22:62230->192.168.1.1:53: i/o timeout.

for some of the connections, the output shows the timing decreasing on subsequent queries but it doesn't report cached rows until the 2nd or further queries.

For instance, when running select name, region from aws_s3_bucket for an aggregator connection with 2 connections:

• Time: 235.8s. Rows returned: 38. Rows fetched: 42. Hydrate calls: 42. Scans: 2. Connections: 2.
• Time: 9.9s. Rows returned: 42. Rows fetched: 42. Hydrate calls: 42. Scans: 2. Connections: 2.
• Time: 65ms. Rows returned: 42. Rows fetched: 42 (cached). Hydrate calls: 0. Scans: 2. Connections: 2.

With 15 connections:

• Time: 489.9s. Rows returned: 307. Rows fetched: 722. Hydrate calls: 722. Scans: 15. Connections: 15.
• Time: 534.0s. Rows returned: 389. Rows fetched: 722. Hydrate calls: 722. Scans: 15. Connections: 15.
• Time: 279.7s. Rows returned: 687. Rows fetched: 722 (48 cached). Hydrate calls: 674. Scans: 15. Connections: 15.
• Time: 394ms. Rows returned: 722. Rows fetched: 722 (482 cached). Hydrate calls: 240. Scans: 15. Connections: 15.
• Time: 83ms. Rows returned: 722. Rows fetched: 722 (cached). Hydrate calls: 0. Scans: 15. Connections: 15.
• Time: 87ms. Rows returned: 722. Rows fetched: 722 (cached). Hydrate calls: 0. Scans: 15. Connections: 15.
• Time: 84ms. Rows returned: 722. Rows fetched: 722 (cached). Hydrate calls: 0. Scans: 15. Connections: 15.

In both cases, the timing starts to decrease on the 2nd run, and then even more on subsequent runs until all rows are cached.

In the 2nd run, are any cached rows/results being used (or maybe just some of the hydrate calls)? As the query time decreases, I was assuming that was from it using some cached info, but it was difficult to tell from the timing/rows info.

Steampipe version (steampipe -v)
Steampipe v0.23.2

To reproduce
Run the query above with at least 2 connections (and 20-30 buckets in each account)

Expected behavior
I'm not sure, maybe improvements to the rows fetched/hydrate calls info?

Additional context
Add any other context about the problem here.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[github-actions]

This issue was closed because it has been stalled for 90 days with no activity.