After the restoration, the execution is expected to resume after the point where checkpointOnRefresh is evaluated so I believe the current behavior is correct, and we have multiple tests checking that the behavior is correct on https://github.com/spring-projects/spring-lifecycle-smoke-tests.

Do you observe a concrete issue (if so, please provide a reproducer)?

Yes, the after restore behavior is correct. But is a context refresh event an event that only occurs once in the lifetime of an application or is a context refresh allowed to happen at any time after an application is started? I think it is allowed to happen at any later time and this is e.g. how spring-cloud allows you to change the configuration at runtime with @RefreshScope. But when this happens a new context refresh event is sent and the onRefresh of DefaultLifecycleProcessor is called which then again triggers a CRaC checkpoint which is unwanted at this time.

I will try to create a small project which reproduces the issue.

I thought the @RefreshScope from spring-cloud would lead to the second invocation of DefaultLifecycleProcessor.onRefresh but I was wrong and it was our own code were we in the ContextRefreshedEvent create a child ApplicationContext and refresh that. I have changed the code of https://github.com/frederikz/spring-boot-crac-demo to demonstrate similar behaviour. I don't know if the way we do it is to blame or if there could be more legitimate use cases that could lead to a second invocation of DefaultLifecycleProcessor.onRefresh which then would take a second CRaC checkpoint after restore.

I am not sure I would recommend the use case you show here with a post restoration application creation, but the change you ask seems to be conceptually in line with the behavior we want for that feature that should only happen after startup, so I will refine our implementation accordingly.