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

Tue May 26 10:49:41 CEST 2026

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20260526/ee2a3b28/attachment.htm>