<div dir="ltr"><div dir="ltr">Dear midPoint community</div><div dir="ltr"><br></div><div dir="ltr">Hi, I'm K from Japan.</div><div dir="ltr"><br>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.<br><br><br>After restoring, other pages (Users, Roles, Resources) work 100% perfectly with full read/write capabilities. Only Tasks are broken.<br><br><br>Could you please review our configuration and logs below?<br><br><br>Infrastructure: midPoint HA Cluster on AWS EKS (Main / Replica)<br><br>Database: Managed by CloudNativePG (CNPG)<br><br>Data Size: 1400MB<br><br><br><b>【commands for backup/restore】</b><br><br><br>①: dump command<br><br>==========================<br><br>kubectl exec -n $NAMESPACE $POD_NAME -c $TARGET_CONTAINER -- \<br>  pg_dump -U postgres -Fc "$DB" -f /var/lib/postgresql/data/backup.dump; then<br><br>kubectl cp ${NAMESPACE}/${POD_NAME}:var/lib/postgresql/data/backup.dump "$BACKUP_FILE" -c $TARGET_CONTAINER<br><br>kubectl exec -n $NAMESPACE $POD_NAME -c $TARGET_CONTAINER -- rm /var/lib/postgresql/data/backup.dump<br><br>==========================<br><br><br><br>②: restore command<br><br>==========================<br><br>kubectl exec -n $NAMESPACE $PRIMARY_POD -c $CONTAINER_NAME -- \<br>  env PGOPTIONS="-c default_transaction_read_only=off" \<br>  psql -U postgres -c "CREATE DATABASE $NEW_DB OWNER postgres;" 2>&1 >> $GITHUB_STEP_SUMMARY;<br><br>kubectl exec -n $NAMESPACE $PRIMARY_POD -c $CONTAINER_NAME -i -- \<br>  env PGOPTIONS="-c default_transaction_read_only=off" \<br>  pg_restore -U postgres -d "$NEW_DB" \<br>  --clean --if-exists --no-owner --no-privileges --verbose < ./restore.dump 2>&1<br>          <br>==========================<br><br><br>Our backup methods are show below.<br><br>①: create a new database.(database name: AAAAA_YYYYMMDD_HHMMSS)<br>②: grant permissions such as ones related to scheme)<br>③: delete a current used DB whom name is AAAA<br><br>④: rename ①'s database(AAAAA_YYYYMMDD_HHMMSS ➤ AAAAA)<br>⑤: the name defined in the configuration file of a cluster would matches ④'s database name.<br>    That means it could be restored properly.<br><br>      <br><br><b>【The UI error message】</b><br><br>After the restore completes, User, Role, and Resource management UI pages work 100% perfectly.<br><br><br>We can create and modify users manually without any database write errors. However, the Task management UI completely crashes. <br><br><br>1. Accessing the task list or trying to create a new task results in an immediate Wicket error:<br><br><br>==========================<br><br>  org.apache.wicket.WicketRuntimeException: Error attaching this container for rendering: [WebMarkupContainer [Component id = body]]<br><br>==========================<br><br><br>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). <br>It logs that it successfully purges 54 ghost/orphaned tasks that do not exist in the repo:<br><br><br>==========================<br><br><b>【An error on UI】</b><br><br>Cannot list jobs from Quartz scheduler, skipping second part of synchronization procedure.<br><br><br><b>【An error on log】</b><br><br>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." <br><br>==========================<br><br><b>【Logs & Analysis】<br></b><br>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:<br><br><br>=========================<br><br>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." <br><br>=========================<br><br><br>But right after, it throws a fatal NullPointerException during UI rendering because it cannot resolve the execution state/times:<br><br><br>=========================<br>java.lang.NullPointerException: Cannot invoke "com.evolveum.midpoint.task.quartzimpl.quartz.NextStartTimes.getNextScheduledRun()" because "times" is null<br><br>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.<br><br>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)<br><br>==========================<br><br><br>Please refer to some log data too<br><br>==========================<br><br>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).<br><br> <br>org.apache.wicket.WicketRuntimeException: Error attaching this container for rendering: [WebMarkupContainer [Component id = body]]<br>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]]: {}<br><br>        <br>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<br><br>      <br>org.apache.wicket.WicketRuntimeException: Error attaching this container for rendering: [WebMarkupContainer [Component id = body]]<br>  <br>2026-05-26 16:20:59,032 [] [http-nio-8080-exec-2] ERROR (com.evolveum.midpoint.web.security.LoggingRequestCycleListener): Error occurred during page rendering.<br><br>==========================<br><br><b>【The log data on the main DB】</b><br><br>The main DB's log data is shown below. <br><br>==========================<br><br>{"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"}}<br><br>{"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"}}<br><br><br>==========================<br><br><b>【Questions】</b><br><br>1: Has anyone successfully implemented a pure PostgreSQL logical pg_dump/pg_restore strategy for midPoint clusters without running into this Quartz store mismatch?<br><br><br>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?<br><br><br>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?<br><br><br>Any insights, workarounds, or hidden configuration settings (e.g., TaskManager cluster settings) would be highly appreciated!<br><br>Thank you in advance!<br>Best regards.<br></div><div dir="ltr"><br></div><div>Frost K</div><div dir="ltr">A member of a company in Japan.</div>
</div>