Skip to main content

​
Diagnose an HTTP 500 on checklist save

When a user checks or unchecks an item and the change doesn’t stick, the save request may have failed on the server.
  1. Reproduce the action and immediately check the Polarion server log.
  2. Look for a stack trace originating from the checklist save path, together with a dump of the request parameters (project, and one of document/testrun/plan/workitem, plus the checklist data).
  3. Confirm which target type was involved — the save request only carries one of document, testrun, plan, or workitem. If more than one happens to be present, the system resolves them in that precedence order (document first, then test run, then plan, then work item), so check that the client is sending the parameter you expect.
  4. If the target object (document, test run, plan, or work item) cannot be resolved, or the underlying transaction fails to commit, the server returns a generic HTTP 500 and logs the error with the full parameter dump.
Use the parameter dump for support ticketsIf you need to escalate a save failure to support, attach the full log entry rather than a screenshot of the error. The server logs every request parameter (project, target IDs, checklist ID) on failure, which is usually enough to pinpoint whether the problem is a missing object, a permission issue, or a transaction conflict.
Only POST is supportedThe checklist save endpoint only accepts POST requests. If a browser extension, proxy, or custom integration issues a GET or PUT against the same URL, it will always fail — this is expected behavior, not a bug.
Checklist save request flow from the browser through the save endpoint to a success or failure response

​
Understand “InvocationTargetException” / “UnresolvableObjectException” in the log

Some deployments see the Polarion log fill up with InvocationTargetException errors wrapping an UnresolvableObjectException or UnknownObjectException for a specific work item, but only when the work item is created, not on later edits.
Known log noise on work item creationEvery save on a work item passes through a save hook that keeps the checklist’s _summary field in sync. During creation, this hook can attempt to read the object’s revision history before the new item is fully resolvable in the repository, which throws UnresolvableObjectException/UnknownObjectException. This has been observed independently of templates, attachments, links, permissions, or user role (it affects basic users and admins alike).
If you encounter this pattern:
  1. Confirm the error only appears on work item creation, not on subsequent saves of the same item. That matches the known pattern.
  2. Confirm the checklist value itself was saved correctly despite the log entry (open the work item and check the checklist content).
  3. If the checklist data is present and correct, treat the log entry as noise from the save hook’s summary computation rather than a functional failure.
If you need to rule out the checklist save hook entirely while investigating a save issue, an administrator can disable it globally with the JVM system property:
Server restart required, and it’s an all-or-nothing switchnextedy.checklist.disable.hook is a JVM system property, not a Polarion configuration property — it cannot be set in Administration > Configuration Properties. It must be added to the server’s startup configuration and requires a full server restart to take effect. While enabled, all checklist save-time processing is skipped, including summary field updates and reset-on-type-change — use it only as a temporary diagnostic step, not a permanent setting.

​
Checklist summary fields not updating

The checklist form extension pairs each checklist custom field with a companion summary field that uses the _summary suffix convention (for example, a checklist field dod pairs with dod_summary). Summary computation is not automatic for every checklist — it must first be enabled via the nextedy.checklist._TYPEID_.checklistsIdsForSummary configuration property, which lists which checklist field IDs get summarized for a given work item type. Once enabled, the summary text is recomputed automatically every time the work item is saved. See Summary Field Reference for the full setup procedure.
  1. Confirm the checklist field ID is listed in nextedy.checklist._TYPEID_.checklistsIdsForSummary for the work item’s type — a checklist that isn’t listed there never gets a computed summary, regardless of naming.
  2. Verify the summary field’s ID actually follows the _summary suffix convention for the checklist field it should reflect.
  3. Save the work item again (any save triggers recomputation) and check whether the summary field updates.
  4. If summary computation itself throws an error, it’s logged but does not block the save — check the server log around the time of the save for a stack trace tied to summary computation, separate from any save-error investigation above.
Changing a work item’s type can trigger a separate, previously reported Polarion platform issue where multi-line plain text in the checklist field is converted into rich text.
Tracked upstream Polarion issueThis has been reported to Siemens as a Polarion platform issue, not a Checklist defect. If your checklist content appears reformatted (plain text turned into rich text) immediately after a work item type change, this is the likely cause. You may also report the issue to Siemens yourself via your support channel to help prioritize a fix.
To avoid the practical impact of both the reset behavior and the formatting issue when type changes are common in your workflow, see Multiple Templates per Type and Reset on Type Change, which documents the nextedy.checklist.checklistsIdsForTypeChanges configuration property that resets affected checklists cleanly to the correct type’s template.

​
Verify

You should now see the expected outcome for each scenario:
  • A checklist save that previously failed either succeeds (HTTP 200) or produces a log entry with a full parameter dump you can act on or escalate.
  • InvocationTargetException / UnresolvableObjectException entries appearing only at work item creation, with the checklist data itself saved correctly, are recognized as known log noise rather than a functional defect.
  • Summary fields (<fieldId>_summary) reflect the current checklist state after every save.
  • Checklist content survives a work item type change without unexpected reformatting, or you’ve documented it as a known, reported Polarion issue.

​
See also

KB Articles
  • Checklist is marked as readonly.
  • Freeze the checklist on some statuses
  • How to reset Checklist to the Template on WI type change
Support TicketsSource Code
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistConf.java
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/internal/hook/SaveHandler.java
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/IChecklistService.java
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/internal/ChecklistService.java
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/wf/ChecklistResetToTemplate.java
Last modified on August 31, 2026