$sp is not defined" only through AI Search after the Australia patch — the widget works fine everywh

oussamaghaz
Kilo Contributor

Hi everyone,

I'm hoping someone has run into this. Everything in our Employee Center Pro was working fine, we took the Australia patch3-hotfix1 (mid-June), and the next morning AI Search started throwing a server error: "$sp" is not defined, coming from the OOB Now Assist Self Service widget (sp_widget 634bcbc59ff20210210e089c8a0a1ce1), right at its first $sp.getPortalRecord() call.

It hits every user. The instance is a demo instance.

The part that's driving me a bit crazy: **$sp works perfectly everywhere else.** The rest of the portal renders fine, other widgets using $sp are happy — it's only when AI Search renders *this* widget that $sp suddenly isn't there. For reference, other Employee Center pages that use $sp (e.g. the HR To-Dos page) render perfectly — it's strictly the AI Search render path that fails. So to me this smells like a rendering-context problem, not a broken widget.

Here's what I've already chased down: - I checked the Upgrade Details (sys_upgrade_history_log). The widget shows up as **Updated, changed=true**, delivered by patch3-hotfix1 — so the patch genuinely overwrote the base widget. -

My first instinct was to diff the old vs new widget code. Dead end: there's **no previous version stored** in sys_update_version, because the widget was never customized — so the upgrade refreshed it in place and there's nothing to compare against.

- I then looked at what *else* the same patch run applied (changed=true): a bunch of **Data Broker Server Scripts**, a **Composite Data Broker**, an **"Instance with Search"**, and several **Angular providers** — basically the whole AI Search render path moved in this patch. - The sp_instance → column → row → container → page chain is intact, and the AI Search profile/sources are published. Nothing obviously broken on the config side.

My working theory is that the patch rewired the AI Search path so the widget's server script now runs **outside the Service Portal rendering context**, which is the only thing that injects $sp (GlideSPScriptable). If it's invoked through a data broker or the AIS composite renderer instead, $sp would simply never be there. So, a few questions:

- Has anyone hit "$sp" is not defined on the Now Assist Self Service widget after the Australia (or Yokohama) patch?

- Is there a known PRB where the AI Search results path calls this widget without an SP context?

-Any idea how to resolve it?

I'm pulling the full server stack trace right now and I'll drop it in the comments once I have it. Thanks a lot for any pointers!

 

oussamaghaz_0-1782677998484.png

oussamaghaz_1-1782678036885.png

 

 

0 REPLIES 0