Closed jeffreymp17 closed 7 months ago
@ParthaI i created this issue, because is continue happening
Hello @jeffreymp17,
I hope this message finds you well. I am writing to sincerely apologize for the recurring issue you've been experiencing recently. I understand how frustrating and inconvenient this must be for you, and I want to assure you that resolving this matter is our top priority.
After implementing the recent bug fix for the end_time
column issue, I didn't observe any similar problems with the other TIMESTAMP columns. I executed the query with most possible lifecycle states (which were manually simulated) and in each case, I successfully retrieved the value.
I apologize for the oversight in not running the query with the DELETION_PENDING
backup state. In this state, it appears that we are receiving null values for both the start_time
and end_time
columns.
A PR has been raised to address this issue across all TIMESTAMP type columns. I am optimistic that this will resolve any similar issues with these types of columns.
Have you observed a similar issue in any columns other than those of the timestamp type?
Test Result:
> select id, instance_name, status, end_time, start_time, window_start_time, enqueued_time from gcp_sql_backup;
+---------------+---------------+---------+----------+---------------------------+---------------------------+---------------------------+
| id | instance_name | status | end_time | start_time | window_start_time | enqueued_time |
+---------------+---------------+---------+----------+---------------------------+---------------------------+---------------------------+
| 1705036282811 | test53 | RUNNING | <null> | 2024-01-12T10:41:22+05:30 | 2024-01-12T10:41:22+05:30 | 2024-01-12T10:41:22+05:30 |
+---------------+---------------+---------+----------+---------------------------+---------------------------+---------------------------+
Time: 1.6s. Rows fetched: 1. Hydrate calls: 0.
> select id, instance_name, status, end_time, start_time, window_start_time, enqueued_time from gcp_sql_backup;
+---------------+---------------+------------+---------------------------+---------------------------+---------------------------+---------------------------+
| id | instance_name | status | end_time | start_time | window_start_time | enqueued_time |
+---------------+---------------+------------+---------------------------+---------------------------+---------------------------+---------------------------+
| 1705036282811 | test53 | SUCCESSFUL | 2024-01-12T10:42:44+05:30 | 2024-01-12T10:41:22+05:30 | 2024-01-12T10:41:22+05:30 | 2024-01-12T10:41:22+05:30 |
+---------------+---------------+------------+---------------------------+---------------------------+---------------------------+---------------------------+
Time: 1.7s. Rows fetched: 1. Hydrate calls: 0.
> select id, instance_name, status, end_time, start_time, window_start_time, enqueued_time from gcp_sql_backup;
+---------------+---------------+------------------+----------+------------+---------------------------+---------------------------+
| id | instance_name | status | end_time | start_time | window_start_time | enqueued_time |
+---------------+---------------+------------------+----------+------------+---------------------------+---------------------------+
| 1705036282811 | test53 | DELETION_PENDING | <null> | <null> | 2024-01-12T10:41:22+05:30 | 2024-01-12T10:41:22+05:30 |
+---------------+---------------+------------------+----------+------------+---------------------------+---------------------------+
Thank You!
Thanks @ParthaI for your work, I'll test the plugin to see if everything is working as a expected
Describe the bug we're getting this error interfaceToColumnValue failed for column
'start_time'
: found , expected number\n when we try to execute a query from this table gcp_sql_backup it seems in some point in your side the value cannot be casted or something like that probably the vlaue cannot be converted in the sql translationSteampipe version (steampipe -v) 0.21.3
Plugin version (steampipe plugin list) v0.47.0
To reproduce
Cannot reproduced but you can make a query to gpc_sql_backup with invalid date or null maybe
Expected behavior
Should return values
Additional context