Loading...
Loading...
The sysauto_script scheduled job, "Prune Search Signal Events" (9a7902735b3310105b1eed35cc81c7e7) as a result of a code error, may cause sys_search_events and its related tables to be incorrectly pruned. If any search application is eligible for pruning, where the application has more search events than the value in sys_properties “glide.search.analytics.max_search_signal_events”, there is a chance that sys_search_events records can be removed for search applications other than the eligible ones.
Create the sys_properties record "glide.search.analytics.max_search_signal_events" and set it to a low number to avoid having to create over 500,000 search events. If it already exists, update the value instead to a low number. 2. Ensure search events for multiple applications exist. 3. Run the prune job and observe that any application evaluated after the application that has over than "glide.search.analytics.max_search_signal_events" events has the same number of records pruned.
Using the URL below, uncheck the "active" flag on the "Prune Search Signal Events" sysauto_script record. https://<instance>.service-now.com/sysauto_script_list.do?sysparm_query=sys_id%3D9a7902735b3310105b1eed35cc81c7e7 This workaround will prevent the faulty code from running on the instance. When this is disabled, sys_search_event and its related tables will not be pruned weekly. The sys_trigger "Prune Search Signal Events" will also be deleted after deactivating the sysauto_script job. Alternatively, this maintenance script can be used to disable the job. -- A maintenance communication is sent on affected instances that will inform about a date/time to update the job proactively. -- FAQ Q: When will this maintenance happen? A: A COMM record will be sent to notify you with the dates and times if determined for maintenance. Q: How can I tell what data can have unintended pruning? A: Out of box, the "glide.search.analytics.max_search_signal_events" sys_property is 500,000. When it is not populated in the instance, the code defaults the value to 500,000. Keeping this value in mind, if you use the URL below: https://<instance>.service-now.com/sys_search_event_list.do?sysparm_query=sys_updated_on%3Cjavascript:gs.beginningOfLast90Days()%5EGROUPBYapplication_id&sysparm_first_row=1&sysparm_view= You will get a grouped list (by application_id). Take note of the highest number returning by application_id. In order to be potentially affected, the application_id group count greater than the "glide.search.analytics.max_search_signal_events" value is the data that can be potentially affected when the scheduled job "Prune Search Signal Events" sysauto_script executes weekly. Q: What does the maintenance do? A: It will disable the "Prune Search Signal Events" sysauto_script record and prevent the prune logic from being ran. Q: What is sys_search_event used for? A: This is used for telemetry and metrics data. The purpose of the sys_search_event table is one of the "Search Suggestions" which uses tables to generate and track relevant search suggestions. You can review data from these tables to gain insight into search suggestions offered in your system. https://www.servicenow.com/docs/bundle/yokohama-platform-administration/page/administer/search-administration/reference/understanding-search-suggestion-tables.html Q: Is there concern for data growth capacity if the "Prune Search Signal Events" sysauto_script scheduled job is disabled? A: No, there is a fallback out of box sys_auto_flush configured for the sys_search_event table that will automatically delete records that are older than 180 days so the sys_search_event table will still be cleaned. Reference to the auto flush: https://<instance>.service-now.com/sys_auto_flush_list.do?sysparm_query=sys_id%3D0180269887e03300f917e55936cb0b0c Q: Will this maintenance have any service impact? A: Updating the "Prune Search Signal Events" sysauto_script record will not have service impact. Cache flush or node restart is NOT required during the maintenance. Q: What is the impact if I do not disable the "Prune Search Signal Events" sysauto_script scheduled job? A: Search applications meeting the condition to be impacted (under "How can I tell what data can have unintended pruning?") above can be at risk to pruning data on sys_search_events and its related tables. Q: Is it possible to set up the sys_properties "glide.search.analytics.max_search_signal_events" record to a higher value to prevent the issue? A: Yes, but it is better to disable the scheduled job "Prune Search Signal Events" sysauto_script record instead to prevent the prune logic from running. Q: Who can disable the "Prune Search Signal Events" sysauto_script record job? A: ServiceNow admins can disable the job. Q: Can I opt out of this maintenance or reschedule? A: Yes, you can opt out of the maintenance, but ensure that the job is disabled as soon as possible. If you need to reschedule, opt out of the maintenance and apply the maintenance script as soon as possible as admin. Rescheduling is not an option. Q: I am below what is considered to be impacted. Why am I receiving this maintenance? A: This is a proactive maintenance. There is no impact receiving the maintenance otherwise. Q: How can I opt out of the maintenance? A: Go to the communication record on the portal that was sent for the notification and click on the Opt out button on the upper right hand side of the form. It is emphasized that you implement the maintenance script in the beginning of the "Workaround" section as soon as possible to be proactive. Q: Can I run this maintenance script on my own? A: Yes, it is attached to this KB and admins can run it on their own in scripts background. Q: What do the outputs look like for the script if it is successful (or not)? A: The outputs will look similar to this: successful run: *** Script: {"changed":true,"at_risk":false,"details":{"valueBefore":"1","valueAfter":"0"},"note":"Scheduled job deactivated","buildName":"Yokohama","buildWar":"glide-yokohama-12-18-2024__patch0-01-14-2025_01-16-2025_1338.zip","reason":"PRB1852402"} rerun after disabling: *** Script: {"changed":false,"at_risk":false,"details":{"valueBefore":"0","valueAfter":"0"},"note":"Prune Search Signal Events job is inactive.","buildName":"Yokohama","buildWar":"glide-yokohama-12-18-2024__patch0-01-14-2025_01-16-2025_1338.zip","reason":"PRB1852402"} running with no populated sysauto_script: *** Script: {"changed":false,"at_risk":false,"details":{"valueBefore":"","valueAfter":""},"note":"Prune Search Signal Events job does not exist.","buildName":"Yokohama","buildWar":"glide-yokohama-12-18-2024__patch0-01-14-2025_01-16-2025_1338.zip","reason":"PRB1852402"} Note that by disabling the sysauto_script for "Prune Search Signal Events" will delete the relevant sys_trigger "Prune Search Signal Events" that calls the job. Q: What am I to expect once the maintenance is completed? What is the validation? A: The sysauto_script for "Prune Search Signal Events" will be disabled, which is a successful validation. Q: Is this maintenance updating the code defect itself or updating the job? A: The hardcode will not be updated. This is only updating the sysauto_script for "Prune Search Signal Events" to disable the job. Q: What if I apply the maintenance script on my own and do not opt out of the maintenance? A: The maintenance will still run on the instance but not perform actions due to the logic check that the maintenance was applied already. However, the COMM record will still report that the maintenance is performed. There no impact as the maintenance is already manually performed. Q: I have an instance that wasn't added for maintenance even though I believe it can be affected by this issue. What do I do? A: Please run the maintenance script attached to this KB. The script is the same version that is being run for the maintenance. There is no risk to running it as it only disables the job. Q: I have an activity occurring at the same time as the maintenance, such as deploying an update set. Will this impact my deployment? A: The maintenance will not interrupt ongoing activities being performed at the same time. However, if the instance is temporarily down due to an activity such as a clone, the maintenance will not proceed and the ServiceNow admin for the instance needs to manually deploy the maintenance script in the workaround section. Q: What versions will address this issue? A: This is addressed in the versions listed in the intended fixed versions at the bottom of the KB. Q: If I disabled the job before upgrading to a fixed version by doing the workaround, will upgrading to the fixed version turn the job back on? A: No, the job will still stay disabled. It is recommended to turn the "Prune Search Signal Events" sysauto_script record job back on once you are on a fixed version. Q: I don't see "glide.search.analytics.max_search_signal_events" in sys_properties. Should I be concerned? A: No, even if it's not populated, out of box in the code, "glide.search.analytics.max_search_signal_events" defaults to 500,000. Q: If this feature is disabled out of box, was this feature ever enabled out of box in the past? A: No, this feature was not enabled out of box since it's release in Vancouver. Setting this feature up requires assistance with technical support.
PRB1852402
Click on a version to see all relevant bugs
ServiceNow Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.