LastSuccess field is NULL in executeRecurringly

[decebals]

I have a custom task like this:

public class MyTask extends RecurringTask<Void> {

    public MyTask(Schedule schedule) {
        super("MyTask", schedule, null);
    }

    @Override
    public void executeRecurringly(TaskInstance taskInstance, ExecutionContext executionContext) {
        Instant lastSuccess = executionContext.getExecution().lastSuccess; // <-- NULL
        // do something
    }
    
}

I observed that executionContext.getExecution().lastSuccess is NULL inside of executeRecurringly method.
Before executing the method in the db I have a value not null for this field.

I use version 11.6
The problem is I do some business with this value and I need a lastSuccess != null. In the past I used version 10.5 without and problem (I'm not sure here).

[decebals]

It's a possibility to achieve this behavior only when I force a run manually using below code:

class SchedulerService {

    public void run(String taskName) {
        log.debug("Run task '{}'", taskName);
        getRecurringTask(taskName).ifPresent(recurringTask -> scheduler.reschedule(TaskInstanceId.of(taskName, RecurringTask.INSTANCE), Instant.now()));
    }

    private Optional<RecurringTask<?>> getRecurringTask(String taskName) {
        return schedulerTasks.stream().filter(recurringTask -> recurringTask.getName().equals(taskName)).findFirst();
    }
    
}

[decebals]

The idea is that at https://github.com/kagkarlsson/db-scheduler/blob/master/db-scheduler/src/main/java/com/github/kagkarlsson/scheduler/SchedulerClient.java#L289 is passed null for lastSuccess and lastFailure.

[decebals]

So, my concrete question is: can I force the execution of a task and to have lastSuccess and lastFailure fields as information (not null)?
It's not clear for me why is passed null for these two fields in SchedulerClient (see my previous comment)

[decebals]

I see now that I have created an issue on this topic in the past 😄.
It's #254 (comment) (it's still open).

[kagkarlsson]

I can agree that a reschedule method that does not reset lastSuccess etc could be useful for these situations. reschedule as it is now was probably intended mostly for use after execution completion, when the CompletionHandler runs