[midPoint] Task UI Breakdown (NullPointerException / Quartz Desync) After Logical Dump/Restore in midPoint HA Cluster (CloudNativePG)

Pavol Mederly mederly at evolveum.com
Mon Jun 1 18:29:36 CEST 2026 

Hello K,

after

> 2026-05-26 16:12:39,854 [TASK_MANAGER] [http-nio-8080-exec-1] ERROR 
> (com.evolveum.midpoint.task.quartzimpl.quartz.TaskSynchronizer): 
> Cannot synchronize repository/Quartz Job Store information for task 
> Task(id:1769760974026-44018-1, name:Export task for IGA: Who has 
> access to what and why No3 (2026-01-30 17:16:13), 
> oid:f764fb6c-c433-4cad-ac1e-ec2dd5958bbd).
>
you should get a full stack trace, indicating the source of the problem.

You may consider providing it here, maybe someone would be able to help you.

Because, in general, I think that backup+restore should not break the tasks.

Best regards,

-- 
Pavol Mederly
Interim Chief Product Officer
evolveum.com

On 26/05/2026 10:49, Frost K via midPoint wrote:
> Dear midPoint community
>
> Hi, I'm K from Japan.
>
> We are facing a critical issue where the Task management UI completely 
> crashes after restoring a logical database dump (pg_dump -U postgres 
> -Fc) into a new database instance via GitHub Actions.
>
>
> After restoring, other pages (Users, Roles, Resources) work 100% 
> perfectly with full read/write capabilities. Only Tasks are broken.
>
>
> Could you please review our configuration and logs below?
>
>
> Infrastructure: midPoint HA Cluster on AWS EKS (Main / Replica)
>
> Database: Managed by CloudNativePG (CNPG)
>
> Data Size: 1400MB
>
>
> *【commands for backup/restore】*
>
>
> ①: dump command
>
> ==========================
>
> kubectl exec -n $NAMESPACE $POD_NAME -c $TARGET_CONTAINER -- \
>   pg_dump -U postgres -Fc "$DB" -f 
> /var/lib/postgresql/data/backup.dump; then
>
> kubectl cp 
> ${NAMESPACE}/${POD_NAME}:var/lib/postgresql/data/backup.dump 
> "$BACKUP_FILE" -c $TARGET_CONTAINER
>
> kubectl exec -n $NAMESPACE $POD_NAME -c $TARGET_CONTAINER -- rm 
> /var/lib/postgresql/data/backup.dump
>
> ==========================
>
>
>
> ②: restore command
>
> ==========================
>
> kubectl exec -n $NAMESPACE $PRIMARY_POD -c $CONTAINER_NAME -- \
>   env PGOPTIONS="-c default_transaction_read_only=off" \
>   psql -U postgres -c "CREATE DATABASE $NEW_DB OWNER postgres;" 2>&1 
> >> $GITHUB_STEP_SUMMARY;
>
> kubectl exec -n $NAMESPACE $PRIMARY_POD -c $CONTAINER_NAME -i -- \
>   env PGOPTIONS="-c default_transaction_read_only=off" \
>   pg_restore -U postgres -d "$NEW_DB" \
>   --clean --if-exists --no-owner --no-privileges --verbose < 
> ./restore.dump 2>&1
>
> ==========================
>
>
> Our backup methods are show below.
>
> ①: create a new database.(database name: AAAAA_YYYYMMDD_HHMMSS)
> ②: grant permissions such as ones related to scheme)
> ③: delete a current used DB whom name is AAAA
>
> ④: rename ①'s database(AAAAA_YYYYMMDD_HHMMSS ➤ AAAAA)
> ⑤: the name defined in the configuration file of a cluster would 
> matches ④'s database name.
>     That means it could be restored properly.
>
>
>
> *【The UI error message】*
>
> After the restore completes, User, Role, and Resource management UI 
> pages work 100% perfectly.
>
>
> We can create and modify users manually without any database write 
> errors. However, the Task management UI completely crashes.
>
>
> 1. Accessing the task list or trying to create a new task results in 
> an immediate Wicket error:
>
>
> ==========================
>
>   org.apache.wicket.WicketRuntimeException: Error attaching this 
> container for rendering: [WebMarkupContainer [Component id = body]]
>
> ==========================
>
>
> 2: During pod startup and task page initialization, midPoint's 
> TaskSynchronizer attempts to reconcile the midPoint repo (m_task) with 
> the Quartz job store (qrtz_ tables).
> It logs that it successfully purges 54 ghost/orphaned tasks that do 
> not exist in the repo:
>
>
> ==========================
>
> *【An error on UI】*
>
> Cannot list jobs from Quartz scheduler, skipping second part of 
> synchronization procedure.
>
>
> *【An error on log】*
>
> 2026-05-26 16:12:39,859 [] [http-nio-8080-exec-1] INFO 
> (com.evolveum.midpoint.task.quartzimpl.quartz.TaskSynchronizer): 
> Synchronization of midpoint and Quartz tasks store finished. 
> Processing of 0 task(s) existing in midPoint repository has been 
> successful, while processing of 0 task(s) has failed. 0 task(s) has 
> been updated and 54 task(s) has been removed from Quartz job store, 
> because they are not present in midPoint repository."
>
> ==========================
>
> *【Logs & Analysis】
> *
> During pod startup and task page initialization, midPoint's 
> TaskSynchronizer attempts to reconcile the midPoint repo (m_task) with 
> the Quartz job store (qrtz_ tables). It logs that it successfully 
> purges 54 ghost/orphaned tasks that do not exist in the repo:
>
>
> =========================
>
> 2026-05-26 16:12:39,859 [] [http-nio-8080-exec-1] INFO 
> (com.evolveum.midpoint.task.quartzimpl.quartz.TaskSynchronizer): 
> Synchronization of midpoint and Quartz tasks store finished. 
> Processing of 0 task(s) existing in midPoint repository has been 
> successful, while processing of 0 task(s) has failed. 0 task(s) has 
> been updated and 54 task(s) has been removed from Quartz job store, 
> because they are not present in midPoint repository."
>
> =========================
>
>
> But right after, it throws a fatal NullPointerException during UI 
> rendering because it cannot resolve the execution state/times:
>
>
> =========================
> java.lang.NullPointerException: Cannot invoke 
> "com.evolveum.midpoint.task.quartzimpl.quartz.NextStartTimes.getNextScheduledRun()" 
> because "times" is null
>
> 2026-05-26 16:20:59,031 [] [http-nio-8080-exec-2] ERROR 
> (com.evolveum.midpoint.gui.impl.component.data.provider.SelectableBeanContainerDataProvider): 
> Couldn't list objects.
>
> 2026-05-26 16:20:59,031 [MODEL] [http-nio-8080-exec-2] WARN 
> (com.evolveum.midpoint.model.impl.controller.ModelController): 
> Couldn't search objects in task manager, reason: Cannot invoke 
> "com.evolveum.midpoint.task.quartzimpl.quartz.NextStartTimes.getNextScheduledRun()" 
> because "times" is null (class java.lang.NullPointerException)
>
> ==========================
>
>
> Please refer to some log data too
>
> ==========================
>
> 2026-05-26 16:12:39,854 [TASK_MANAGER] [http-nio-8080-exec-1] ERROR 
> (com.evolveum.midpoint.task.quartzimpl.quartz.TaskSynchronizer): 
> Cannot synchronize repository/Quartz Job Store information for task 
> Task(id:1769760974026-44018-1, name:Export task for IGA: Who has 
> access to what and why No3 (2026-01-30 17:16:13), 
> oid:f764fb6c-c433-4cad-ac1e-ec2dd5958bbd).
>
>
> org.apache.wicket.WicketRuntimeException: Error attaching this 
> container for rendering: [WebMarkupContainer [Component id = body]]
> 2026-05-26 16:20:59,033 [] [http-nio-8080-exec-2] WARN 
> (com.evolveum.midpoint.web.page.error.PageError): Creating error page 
> for code org.apache.wicket.WicketRuntimeException, exception Error 
> attaching this container for rendering: [WebMarkupContainer [Component 
> id = body]]: {}
>
>
> Caused by: java.lang.NullPointerException: Cannot invoke 
> "com.evolveum.midpoint.xml.ns._public.common.common_3.TaskType.getObjectRef()" 
> because the return value of 
> "com.evolveum.midpoint.web.component.util.SelectableBean.getValue()" 
> is null
>
>
> org.apache.wicket.WicketRuntimeException: Error attaching this 
> container for rendering: [WebMarkupContainer [Component id = body]]
>
> 2026-05-26 16:20:59,032 [] [http-nio-8080-exec-2] ERROR 
> (com.evolveum.midpoint.web.security.LoggingRequestCycleListener): 
> Error occurred during page rendering.
>
> ==========================
>
> *【The log data on the main DB】*
>
> The main DB's log data is shown below.
>
> ==========================
>
> {"level":"info","ts":"2026-05-26T07:09:31.926059022Z","logger":"postgres","msg":"record","logging_pod":"postgresql-XXXX-4","record":{"log_time":"2026-05-26 
> 07:09:31.918 
> UTC","user_name":"XXXXXX_user","database_name":"XXXXX5","process_id":"11666","connection_from":"10.0.XX.XX:XXXXX","session_id":"6a15472b.2d92","session_line_num":"1","command_tag":"idle","session_start_time":"2026-05-26 
> 07:09:31 
> UTC","virtual_transaction_id":"13/0","transaction_id":"0","error_severity":"FATAL","sql_state_code":"57P01","message":"terminating 
> connection due to administrator 
> command","application_name":"XXXX-XXXX","backend_type":"client 
> backend","query_id":"0"}}
>
> {"level":"info","ts":"2026-05-26T07:09:31.926071471Z","logger":"postgres","msg":"record","logging_pod":"postgresql-XXXXX-4","record":{"log_time":"2026-05-26 
> 07:09:31.918 
> UTC","user_name":"XXXXX5_user","database_name":"XXXXX5","process_id":"11667","connection_from":"10.0.XX.XX:XXXXX","session_id":"6a15472b.2d93","session_line_num":"1","command_tag":"idle","session_start_time":"2026-05-26 
> 07:09:31 
> UTC","virtual_transaction_id":"15/0","transaction_id":"0","error_severity":"FATAL","sql_state_code":"57P01","message":"terminating 
> connection due to administrator 
> command","application_name":"XXXX-XXXX","backend_type":"client 
> backend","query_id":"0"}}
>
>
> ==========================
>
> *【Questions】*
>
> 1: Has anyone successfully implemented a pure PostgreSQL logical 
> pg_dump/pg_restore strategy for midPoint clusters without running into 
> this Quartz store mismatch?
>
>
> 2: What is the recommended best practice to safely sanitize, unlock, 
> or force-reinitialize the Quartz relational tables (qrtz_*) during an 
> active database migration or environment cloning?
>
>
> 3: Should we explicitly strip task/node types during dump or is there 
> a safe API method to tell midPoint to rebuild its scheduler states 
> from scratch upon target-pointing?
>
>
> Any insights, workarounds, or hidden configuration settings (e.g., 
> TaskManager cluster settings) would be highly appreciated!
>
> Thank you in advance!
> Best regards.
>
> Frost K
> A member of a company in Japan.
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> https://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260601/12a23b6c/attachment.htm>

More information about the midPoint mailing list