Skip to content
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(automation_tokens): Fix decodeBodyMap for string to time.Time #619

Merged
merged 3 commits into from
Feb 27, 2025

Conversation

Jesse-Hills
Copy link
Contributor

All Submissions:

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

  • Does your submission pass tests?

Changes to Core Features:

  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you successfully run tests with your changes locally?

User Impact

Resolves #575

This change resolves the issue in decodeBodyMap when attempting to parse strings as time.Time when the returned value is an empty string.

It appears the API changed its default behaviour since support for AutomationTokens was added, most notably:

  • In the request it used to accept the zero value of time.Time (0001-01-01T00:00:00Z) for ExpiresAt which resulted in a token with no expiry ("expires_at":null)
    • This no longer works and a time in the past is invalid input, to create a token with no expiry you must explicitly set "expires_at":null or omit it from the request.
  • In the response it used to return the zero value of time.Time for last_used_at (can be seen in the diff for the test fixtures) which decoded fine but the default response has changed to an empty string which now fails to parse.
    • A token with no expiry now returns "expires_at":"" which will result in the same error being seen by "last_used_at":"" in the linked issue.

Are there any considerations that need to be addressed for release?

This should be low risk as the change only impacts the decoding of objects that have a time.Time field, and only changes the behaviour if the endpoint returned an empty string for that field - meaning the endpoint wouldn't currently work without this change.

@Jesse-Hills Jesse-Hills requested a review from a team as a code owner February 25, 2025 15:37
@Jesse-Hills Jesse-Hills changed the title fix(automation_tokens): Fix decodeBodyMap for string to fix(automation_tokens): Fix decodeBodyMap for string to time.Time Feb 25, 2025
@anthony-gomez-fastly
Copy link
Contributor

Hi @Jesse-Hills please update your branch to be up to date with main and note your change in the changelog

@Jesse-Hills Jesse-Hills force-pushed the fix_automation_token_creation branch 2 times, most recently from 4c23a69 to 8b839d5 Compare February 26, 2025 00:16
…es in API response

- Update `CreateAutomationTokenInput` to allow omitting ExpiresAt and have a token that doesn't expire
- Update decoder to handle empty string for time.Time values
@Jesse-Hills Jesse-Hills force-pushed the fix_automation_token_creation branch from 8b839d5 to 9afbfc0 Compare February 27, 2025 00:49
@Jesse-Hills
Copy link
Contributor Author

Hi @anthony-gomez-fastly, I've made the requested changes, please let me know if there are any other blockers.

Copy link
Contributor

@anthony-gomez-fastly anthony-gomez-fastly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, ty!

@kpfleming kpfleming merged commit 625a783 into fastly:main Feb 27, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

decodeBodyMap fails for newly created AutomationToken
3 participants