-
Notifications
You must be signed in to change notification settings - Fork 420
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: for 1624 resource monitor timestamps are always considered to have changed #2214
Conversation
Hey @RichBarnes, thanks for the PR! I will add review comments (and one of @sfc-gh-jcieslak @sfc-gh-swinkler will also take a look). |
@RichBarnes you have 2 approves but still 2 conflicts that must be resolved before merging. :) |
Conflicts should be fixed, had issues with my local branch/git :) |
cbc8aeb
/ok-to-test sha=cbc8aeb3a8b63a3a3925234256203139a8ccf742 |
Integration tests failure for cbc8aeb3a8b63a3a3925234256203139a8ccf742 |
@RichBarnes merged! Thanks for the contribution. 🎊 We will release it with the new version today or tomorrow. |
Summary
Three changes:
validation logic requires both frequency and start_timestamp to be retrieved if either has been altered. If start_timestamp is set to immediately it has always changed on second terraform apply. Updated to set the haschanged boolean if either has been modified to correctly pass validation.
When start_timestamp is set to a specific date time, this is stored in Snowflake as a UTC date with a local offset. This causes an incorrect date to be returned and written to the tf state file. Added code to parse returned UTC back into a local format.
previous suspend_trigger naming support appears to cause issues once the start_timestamp problems are fixed. Changed logic to and rather then or's which resolved the issue.
Noticed a separate issue with the sql for trigger changes, if credit_quota hasn't been set then that line isn't included in the SQL builder which results in malformed sql and an error back from Snowflake. This should be raised as a separate fix/bug ticket.
The minor notify_users attribute behaviour should be resolved under another fix ticket.
Test Plan
Setting start_timestamp to IMMEDIATELY or a change to start_timestamp and running terraform apply twice reproduces the issue. Post fix, changing these values results in desired behaviour and no errors.
Ran existing tests as only logic minor changes to hasChanged logic and timestamp retrieval.
References
Allow closure of #1624