Cache issues

Geeky
Kilo Guru

Users are facing issues while accessing the records on our instance. They are getting a message "Number of rows removed from this list by Security constraints:"

When they are clearing the browser cache and try again, it is working. 

I tried clearing servicenow cache but it did not work. Issue started occurring since the servicenow applied patch on our instance Jakarta Patch 8 

1 ACCEPTED SOLUTION

We have two nodes for our Prod instance, one is X and other is Y.

When I flushed the cache from the servicenow URL, it was flushing the cache only on X and Y wasn't even getting flushed.

Support Agent tried to flush the cache by logging into the Y node directly but that did not help. They had to restart the node and flush the cache again after restart to fix the issue.

That is why when a user was redirected to node X everything was working fine and when he gets redirected to Y, user was facing issues. It was happening intermittently because users were redirected to X sometimes and Y sometimes.

View solution in original post

7 REPLIES 7

Ahmed Hmeid1
Kilo Guru

This message is seen when security does not pass on a READ "row level" ACL.

 

These ACLs are the ones that do not have a field associated to them, eg it will be called incident and not incident.* or incident.field

 

The only ways I see the cache impacting this is:

 

1) The ACL is reading something from cache

2) The ACL was recently changed and the cache hadn't been cleared on the different nodes (it can take a few seconds for them to receive the messages to clear the cache)

 

I think both are pretty unlikely

Have you tried debugging security? You can select "debug security" in the left navigation menu. This will then show you all ACL executions at the bottom of the page with a series of green ticks and red crosses. The red crosses are the ones that failed and you can have a look at why security failed on those ones to identify why they didn't have access to some of the records.

 

The issue with row level READ security is it shouldn't really be used to hide some records and not others.This is because when a user goes to the list, it will load up the first 20 results for example, and then check if you can see them. This might result in seeing only 1 record and the other 19 being hidden due to security. They can then go to page two and see 15 out of the 20, page three see a 0 out of the 20 and page four see all 20. It's very unpredictable, so depending on how the users were ordering their lists, they would get different results

We have two nodes for our Prod instance, one is X and other is Y.

When I flushed the cache from the servicenow URL, it was flushing the cache only on X and Y wasn't even getting flushed.

Support Agent tried to flush the cache by logging into the Y node directly but that did not help. They had to restart the node and flush the cache again after restart to fix the issue.

That is why when a user was redirected to node X everything was working fine and when he gets redirected to Y, user was facing issues. It was happening intermittently because users were redirected to X sometimes and Y sometimes.

Geeky
Kilo Guru

We have two nodes for our Prod instance, one is X and other is Y.

When I flushed the cache from the servicenow URL, it was flushing the cache only on X and Y wasn't even getting flushed.

Support Agent tried to flush the cache by logging into the Y node directly but that did not help. They had to restart the node and flush the cache again after restart to fix the issue.

That is why when a user was redirected to node X everything was working fine and when he gets redirected to Y, user was facing issues. It was happening intermittently because users were redirected to X sometimes and Y sometimes.