> ## Documentation Index
> Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Save Errors and Version Compatibility

> Diagnose save failures, log noise, and Polarion version-related formatting quirks that affect Nextedy CHECKLIST.

export const LastReviewed = ({date}) => {
  if (!date) return null;
  const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", {
    year: "numeric",
    month: "long",
    day: "numeric",
    timeZone: "UTC"
  });
  return <p className="mt-10 text-sm text-gray-400 dark:text-zinc-500 not-prose">
      Last reviewed on {formatted}
    </p>;
};

## 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.

<Tip>
  **Use the parameter dump for support tickets**

  If 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.
</Tip>

<Warning>
  **Only POST is supported**

  The 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.
</Warning>

<Frame>
  <img src="https://mintcdn.com/none-17b4493f/892YPUCat-q05Sxp/checklist/diagrams/guides/troubleshooting/save-errors-and-compatibility/diagram-1.svg?fit=max&auto=format&n=892YPUCat-q05Sxp&q=85&s=3d88742bd1c05eb2d929de41e6e6be24" alt="Checklist save request flow from the browser through the save endpoint to a success or failure response" style={{ maxWidth: "720px", width: "100%" }} width="700" height="480" data-path="checklist/diagrams/guides/troubleshooting/save-errors-and-compatibility/diagram-1.svg" />
</Frame>

## 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.

<Warning>
  **Known log noise on work item creation**

  Every 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).
</Warning>

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:

```text theme={null}
nextedy.checklist.disable.hook=true
```

<Warning>
  **Server restart required, and it's an all-or-nothing switch**

  `nextedy.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.
</Warning>

## 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](/checklist/reference/summary-field) 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.

## Version-related formatting issue on work item type change

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.

<Warning>
  **Tracked upstream Polarion issue**

  This 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.
</Warning>

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](/checklist/guides/templates/multiple-templates-per-type), 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

* [Checklist Is Marked Read-Only](/checklist/guides/troubleshooting/checklist-readonly)
* [Duplicate, Type-Change, and Formatting Issues](/checklist/guides/troubleshooting/duplicate-and-type-change-issues)
* [Multiple Templates per Type and Reset on Type Change](/checklist/guides/templates/multiple-templates-per-type)
* [Summary Field Reference](/checklist/reference/summary-field)
* [Reference](/checklist/reference/index)

<Accordion title="Sources">
  **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 Tickets**

  * [#6781](https://support.nextedy.com/helpdesk/tickets/6781)
  * [#4947](https://support.nextedy.com/helpdesk/tickets/4947)
  * [#6408](https://support.nextedy.com/helpdesk/tickets/6408)

  **Source 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`
</Accordion>

<LastReviewed date="2026-08-31" />