Introduction

Users on Traditional UI applications may encounter the following UI errors when interacting with Repeating Grids:

Failed to find instance @baseclass.RuleName of type Rule-Obj-Activity
Failed to find instance @baseclass.pyUpdateRTEContent of type Rule-HTML
Failed to find instance @baseclass.SSO-Web-Redirect of type Rule-Obj-HTML

These errors occurs during UI rendering when the platform is unable to resolve a required HTML section rule from the runtime context of a Repeating Grid row.

Symptoms

• A screen containing a Repeating Grid fails to render or displays a runtime UI error.
• The error is triggered when clicking a button or invoking an action within a Repeating Grid.
• The issue may occur only for specific rows or under certain data conditions.
• Server logs show a RuleNotFoundException for a missing Rule‑HTML‑Section.

What Is a Repeating Grid?

A Repeating Grid is a Pega UI construct used to render a list of clipboard pages as structured rows, each sharing the same set of columns and controls. It is one of the primary ways to display multi-row data in Pega applications — supporting inline editing, row-level actions, sorting, and filtering across a uniform set of page instances.

At runtime, the grid iterates over a Page List property, rendering one row per embedded page. Each row operates within the context of the page it represents, meaning that any rule invoked from within a row — whether an activity, local action, or section — is expected to resolve against the class of that embedded page.

How Data Is Stored: Code-Pega-List and pxResults

When a Repeating Grid is backed by a Report Definition, Obj-Browse, or a List-type Data Page, Pega stores the query results in a standard Page List property called .pxResults. The container page that holds this list is automatically assigned the system class Code-Pega-List.

This is a critical distinction:

• The container page (class Code-Pega-List) holds the list as a whole and is used by framework-level activities such as Obj-Browse and ReloadSection
• The individual embedded pages within .pxResults() each carry their own pxObjClass, which identifies their specific application class
• Any rule invoked from within a grid row is resolved against the pxObjClass of the individual row page, not the Code-Pega-List container

When pxObjClass is empty or absent on a .pxResults() page, the runtime class of that row becomes effectively undefined — a condition known as classless. At this point, any rule lookup triggered from that row will fall through to @baseclass, since the engine has no valid class to search.

In a Repeating Grid, pxObjClass must be correctly set on each .pxResults() page at the time the grid renders and at the time any UI event fires. If the value is lost between render and interaction (for example, after a section reload, a tab switch, or an idle-session flush), the engine loses its frame of reference and defaults to @baseclass.

Why Buttons in Repeating Grids Are Particularly Susceptible

pxButton is an auto-generated control. Unlike explicitly authored sections or activities, its event-processing logic does not re-anchor the page class prior to invoking the referenced rule. This means that if the class context of the triggering row is already lost at the moment the click fires, the button has no mechanism to recover it — it simply passes whatever context it finds (potentially @baseclass or blank) to the server.

This was identified as a systematic issue in Pega 7.x, where buttons in repeating layouts acquired incorrect DOM IDs under certain refresh configurations, breaking the row-index encoding that the framework relies on to locate the correct .pxResults() page. The same underlying fragility persists in later versions under different triggers.

Conditions

This issue can occur under the following conditions:

• A Repeating Grid contains buttons, dynamic actions, or conditional logic.
• An error is raised from within the row context of the grid.
• Error handling attempts to render an HTML section (for example, a standard error display section such as ShowErrors).
• The referenced section is not accessible or applicable to the class of the Repeating Grid row page.
• The section cannot be resolved from the active ruleset stack during rule assembly.

Steps to Reproduce

The following steps cover the typical repeat-grid scenario:

1. Create a Section rule containing a Repeating Grid layout
2. Set the Repeating Grid's data source to a page list of class Code-Pega-List
3. Add a pxButton control inside one of the grid columns
4. Configure the button's OnClick event to invoke a Local Action or Activity defined in a specific application class (not @baseclass)
5. In the section's Pages & Classes tab, define the page and its expected class
6. Run the application and navigate to the section containing the grid
7. Click the button inside the grid row — the error "Failed to find instance @baseclass" is thrown.

Root cause

The core root cause is runtime class context loss on the pxResults() page within Code-Pega-List-sourced Repeating Grids. When the Repeating Grid renders, the embedded pxResults pages are expected to carry a valid pxObjClass. However, due to how Code-Pega-List manages its page list entries, the pxObjClass of individual pxResults pages may be empty or unresolved at runtime.

When the user clicks a pxButton within an affected row, the event processing logic — using the current page context of that row — finds no valid class and defaults to @baseclass for rule resolution. Since the intended rule (Local Action, Activity, HTML Rule, etc.) does not exist at @baseclass, the lookup fails and the error is thrown.

Contributing factors identified across reported incidents:

• pxButton is an auto-generated control; its event processing does not explicitly re-anchor the page class before invoking the referenced rule.
• The Pages & Classes tab configuration in the section is not always sufficient to preserve context for embedded pxResults entries within Code-Pega-List page lists.
• Platform version changes in Pega Infinity '24.x and '25.1.0 altered runtime context-handling behaviour for auto-generated controls, converting previously stable configurations into failures.
• Session-state and tab-switching events (e.g., ReloadSection) can strip the pxObjClass from work pages and list pages mid-session, triggering the same failure pattern outside of Repeating Grids.
• Issues can arise with multiple refresh actions causing loss of page context, leading to incorrect rule resolution from @baseclass.   Having multiple refresh actions on the same UI element is not a recommended best practice, as it can lead to unpredictable behavior such as context loss.  For this, enable the 'Disable Submit On Refresh' option for the refresh actions on your page. This important setting preserves the correct context during refresh operations, preventing the loss of page context that was causing the incorrect rule resolution.

Solution

Apply one or more of the following resolutions depending on the specific scenario:

Resolution 1 — Embed the list within a specific Work Class (Primary Fix)
Instead of sourcing the Repeating Grid from a top-level Code-Pega-List page, save the list as an embedded page within a named work class. This ensures the embedded pxResults pages inherit and retain a stable pxObjClass during all UI interactions.

Resolution 2 — Verify and restore pxObjClass at runtime
Use the Clipboard Viewer or Tracer to confirm whether pxResults pages carry a valid pxObjClass when the section renders. If the value is blank:

• Review the data source configuration and ensure the class is explicitly set
• Consider adding a Page-Set-Messages or Page-New step in the target class prior to grid render, to explicitly initialize the page class context

Resolution 3 — Validate post-upgrade rule and event configuration
For regressions following a platform upgrade:

• Re-save affected Section rules and button configurations to pick up the new runtime context-handling behaviour.
• Run the Application Guardrails check for classless or unresolved page references.
• Cross-reference the Pega Infinity release notes for the target version for known changes to Code-Pega-List or pxButton event processing.

References

Preassembling Rules in an application

Operations and actions in a table layout

Issues related to transient, base class, and optimized properties

Disabling additional reference field refreshes

refreshSection