That query is from the OutSystems built‑in authentication / security layer and is expected behavior; it’s how the platform checks that a user is still active and valid for the tenant on each request.

Where does this query come from?

The pattern:

(@USERID int, @TENANTID int)
SELECT IS_ACTIVE, USERNAME
FROM OSSYS_USER
WHERE ID = @USERID
  AND TENANT_ID = @TENANTID

is executed by the platform runtime (not your code) whenever it needs to validate the current session’s user, e.g.:

• At the beginning of a web request (On Begin Web Request / security checks).
• When executing built‑in actions like CheckUserSession, GetUserId, or when evaluating roles.
• When doing tenant validation in a multi‑tenant environment.

Nothing in your OML will show that query; it’s generated and executed by the platform internally.

Did something change in OutSystems?

If you suddenly see millions of calls, typical reasons are:

1. Traffic / load increased
   More requests → more session validations → more calls to OSSYS_USER.

2. Short session timeout / session loss
   If session timeout is small or sessions are being lost (e.g. load balancer/cookie issues), users get more fresh sessions, causing more checks.

3. More role checks or redirects
   If you recently added more Check<Role> logic, security redirects, or On Begin Web Request logic that forces extra requests, you’ll see more queries.

4. New authentication plugin / custom auth
   Components like AD / MSAL / OAuth flows can cause extra internal validations depending on how you call Login or check users, similar to what is discussed in other auth‑related threads where platform repeatedly checks user active status and other properties in OSSYS_USER during login flows.Expired OutSysyems accounts are not being reactivated through Tablets

The behavior itself (validating user against OSSYS_USER) is long‑standing in O11; it’s not a brand‑new feature.

Why isn’t there a cache?

For security and consistency reasons:

• OutSystems needs to ensure the user is:
  • Still active (IS_ACTIVE = 1),
  • Still in the correct tenant,
  • Not changed by admin / integration (e.g. disabled due to leaving the company or removed access).
• A cache would introduce:
  • Stale data (user disabled but still allowed to operate until cache expires),
  • Invalidation complexity (every change to Users, Tenants, Roles would need instant invalidation across all front‑ends).
• The platform therefore favors authoritative DB checks on each request over cached user status for core security decisions.

What you can do / check

You cannot turn this specific check off, but you can:

1. Verify if the volume is really abnormal
   Compare to the number of HTTP requests and concurrent sessions. One request usually implies at least one such validation query.

2. Check session configuration

   • In Service Center → Administration → Environment Configuration:
     • Increase session timeout slightly if it’s very low.
   • Check if front‑end rotation / load balancer is causing session loss (new sessions → more checks).

3. Review your app logic

   • Avoid unnecessary redirects that trigger multiple requests for a single “page hit”.
   • Avoid recursive / polling patterns that fire many server requests per user per minute.

4. Monitor DB impact

   • Make sure OSSYS_USER has proper indexes (ID, TENANT_ID) – it should by default. If performance is bad, involve your DBAs, but don’t alter system tables without OutSystems Support guidance.

5. If you suspect a regression

   • If this spike correlates with a platform upgrade or infra change, open a Support case with evidence from SQL Profiler / APM showing the before/after pattern.

In short: the query is from the platform’s normal session/user validation. A sudden spike usually reflects increased or more fragmented HTTP traffic/sessions, not a new OutSystems feature, and you can’t replace it with a cache without compromising security.