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

[Workflow notifications] Notifications not processed after clean install #92

Closed
graham-web opened this issue May 3, 2024 · 2 comments · Fixed by #93
Closed

[Workflow notifications] Notifications not processed after clean install #92

graham-web opened this issue May 3, 2024 · 2 comments · Fixed by #93

Comments

@graham-web
Copy link

Testing a clean install of the localgov_workflows_notifications module, we noticed that the hook_cron logic to enqueue entities won't ever run, due to the state variable localgov_workflows_notifications.last_email_run not having been initialised.

In the below code, the default value (current request time) will always be before the calculated "next run" time, making the if-condition fail:

 $request_time = \Drupal::time()->getRequestTime();
  $last_run = \Drupal::state()->get('localgov_workflows_notifications.last_email_run', $request_time);
  $next_run = $last_run + 86400 * $settings->get('email_frequency');
  if ($request_time >= $next_run) {

Resolutions

#90 suggests that the state would be initialised to the install time of the module - should it do this?

Else, amending the if condition to check for a default value would fix the issue. e.g.:

if ($request_time >= $next_run || $request_time == $last_run) {

@stephen-cox
Copy link
Member

Hi @graham-web, thanks for reporting this rather serious bug.

I had initially just set the $last_run to 0 if it wasn't set, but this triggers alerts for all content that is currently in needs review.

Initializing last_email_run when the module is enabled to the current time makes sense for now, although this might change with #90. I'll also add an update hook to set it for current installs.

@stephen-cox
Copy link
Member

This should be fixed with #93

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 a pull request may close this issue.

2 participants