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

Exclude content length errors from recipient_error prop #290

Merged
merged 2 commits into from
Apr 24, 2024

Conversation

whabanks
Copy link
Contributor

@whabanks whabanks commented Apr 23, 2024

Summary | Résumé

The recipient_error property was falsely identifying certain row errors as recipient_errors and incorrectly marking rows as having recipient errors causing API to mis-interpret what error messages to return to the endpoint caller.

Related Issues | Cartes liées

This PR addresses an issue that was blocking the release pipeline following bumps to Utils' version in API.

Test instructions | Instructions pour tester la modification

Release Instructions | Instructions pour le déploiement

None.

Reviewer checklist | Liste de vérification du réviseur

  • This PR does not break existing functionality.
  • This PR does not violate GCNotify's privacy policies.
  • This PR does not raise new security concerns. Refer to our GC Notify Risk Register document on our Google drive.
  • This PR does not significantly alter performance.
  • Additional required documentation resulting of these changes is covered (such as the README, setup instructions, a related ADR or the technical documentation).

⚠ If boxes cannot be checked off before merging the PR, they should be moved to the "Release Instructions" section with appropriate steps required to verify before release. For example, changes to celery code may require tests on staging to verify that performance has not been affected.

Copy link
Member

@andrewleith andrewleith left a comment

Choose a reason for hiding this comment

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

Just a couple of questions on how this works.

@@ -144,4 +147,9 @@ def __eq__(self, other):

@property
def recipient_error(self):
# TODO: This is a bandaid solution. We need to establish why we are calling this Cell property on
# Cells that do not represent a recipient value.
if self.error is not None and "Some messages may be too long due to custom content." in self.error:
Copy link
Member

Choose a reason for hiding this comment

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

Why is this case not considered an error?

Copy link
Member

Choose a reason for hiding this comment

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

Are there some tests that cover what should and should not be considered an error?

@whabanks whabanks merged commit 4e204b1 into main Apr 24, 2024
4 checks passed
@whabanks whabanks deleted the fix/recipient-error-matching branch April 24, 2024 16:20
whabanks added a commit that referenced this pull request Apr 26, 2024
jzbahrai pushed a commit that referenced this pull request Apr 26, 2024
whabanks added a commit that referenced this pull request May 3, 2024
whabanks added a commit that referenced this pull request May 21, 2024
* Reinstate PR #278 which added additional length checks to bulk SMS sends (#293)"

This reverts commit 0146718.

* Reinstate "Exclude content length errors from recipient_error prop (#290)" (#292)"

This reverts commit cd287cf.

* Remove unused parameter

* Fix params

* Bump utils version
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.

None yet

3 participants