We do not need to wait for socket labs to confirm the status of the email we sent before enabling the user to confirm. If they have the code, they got the email.
Given this context and that we no longer need the status property persisted on the email verification entity, we can move the logic to check the socketlabs API to the view layer to be triggered if a user is visiting the verify-email page without a code. This info can still be useful for a user to display potential errors in delivery but does not need to be triggered for each verification but on an, as needed basis.
NOTE: we could consider keeping the status field on verification if we want to cache the status response from socketlab, but likely easier to just request and display what we receive as it simplifies the data model and requires less testing.
We do not need to wait for socket labs to confirm the status of the email we sent before enabling the user to confirm. If they have the code, they got the email.
Given this context and that we no longer need the status property persisted on the email verification entity, we can move the logic to check the socketlabs API to the view layer to be triggered if a user is visiting the verify-email page without a code. This info can still be useful for a user to display potential errors in delivery but does not need to be triggered for each verification but on an, as needed basis.
NOTE: we could consider keeping the status field on verification if we want to cache the status response from socketlab, but likely easier to just request and display what we receive as it simplifies the data model and requires less testing.
┆Issue is synchronized with this Jira Task