<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello K,</p>
<p>after</p>
<p>
<blockquote type="cite">
<p>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).</p>
<pre class="moz-signature" cols="72"></pre>
</blockquote>
you should get a full stack trace, indicating the source of the
problem.</p>
<p>You may consider providing it here, maybe someone would be able
to help you.</p>
<p>Because, in general, I think that backup+restore should not break
the tasks.</p>
<p>Best regards,</p>
<pre class="moz-signature" cols="72">--
Pavol Mederly
Interim Chief Product Officer
evolveum.com</pre>
<div class="moz-cite-prefix">On 26/05/2026 10:49, Frost K via
midPoint wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANfuxmoeBe5VZyw_ZojB+Cxn-9UDLkB1-fGW=1Gg-X92208BrA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
midPoint mailing list
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a class="moz-txt-link-freetext" href="https://lists.evolveum.com/mailman/listinfo/midpoint">https://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</blockquote>
</body>
</html>