Transaction Quota Rules, `order` field

NS
Kilo Sage
Hello, I want to set longer timeout duration for Table API calls by a specific user. Setting up a new `sysrule_quota` record "Custom REST API request timeout" to catch those API calls is simple enough. I want to avoid modifying the OOB records since this is part of a scoped application.
So I have a `sysrule_quota` record set up with a low execution order of -9001. But the problem is there is no way of stopping the further processing of the Transaction Quota Rules. Eventually the OOB "REST Table API request timeout" comes up and matches the conditions, which causes my API call to time out.

My questions are:
1. Is there any way to stop processing after the match?
2. What is the point of `order` field in `sysrule_quota` if the processing does not stop after a match? Based on the log entries the `glide.quota.manager` evaluates the rules within milliseconds of each other.
3. What does the field `sys_overrides` do in `sysrule_quota`? I tried setting the OOB rule in that field in my new rule, but nothing happened.
4. Is my only solution to also modify the OOB record?


Here are log entries of what happens, showing that there are three matches in the Transaction Quota Rules and the OOB "REST Table API request timeout" hits limit values, cancelling the transaction:
 
02:37:35.054 - glide.quota.manager - QuotaFinder: > Trying to match against urlMATCH_RGX.*/api/now(/v[0-9]+)?/batch.*^urlLIKEsysparm_quota_rule=multipart_stream^type=batch_rest^EQ
02:37:35.054 - glide.quota.manager - QuotaFinder: > Trying to match against type=rest^userSTARTSWITHmagic_user^EQ
02:37:35.055 - glide.quota.manager - QuotaFinder: > Assigning quota "Custom REST API request timeout" with filter: type=rest^userSTARTSWITHmagic_user^EQ to transaction: URL= /api/now/table/redacted, THREAD= API_INT-thread-2, FG= true, TYPE= 7, STATE= 1, USER= magic_user, TIME= 1,116, MEM= 0, ATTRIBUTES= {X-Transaction-Source=Session-Type=non-interactive, user-agent=PostmanRuntime/7.40.0}

02:37:35.055 - glide.quota.manager - QuotaFinder: > Trying to match against type=rest^urlMATCH_RGX.*/api/now(/v[0-9]+)?/import.*^EQ
02:37:35.055 - glide.quota.manager - QuotaFinder: > Trying to match against type=rest^urlMATCH_RGX.*/api/now(/v[0-9]+)?/table.*^EQ
02:37:35.055 - glide.quota.manager - QuotaFinder: > Assigning quota "REST Table API request timeout" with filter: type=rest^urlMATCH_RGX.*/api/now(/v[0-9]+)?/table.*^EQ to transaction: URL= /api/now/table/redacted, THREAD= API_INT-thread-2, FG= true, TYPE= 7, STATE= 1, USER= magic_user, TIME= 1,116, MEM= 0, ATTRIBUTES= {X-Transaction-Source=Session-Type=non-interactive, user-agent=PostmanRuntime/7.40.0}

02:37:35.056 - glide.quota.manager - QuotaFinder: > Trying to match against typeINlist,form,xmlhttp,report,textsearch^foreground=true^urlNOT LIKEsys.scripts^EQ
02:37:35.056 - glide.quota.manager - QuotaFinder: > Trying to match against type=rest^ORtype=json^urlNOT LIKEsysparm_payload_type=edge_encryption_distribution^urlNOT LIKEsysparm_payload_type=machine_learning_download^urlNOT LIKEsysparm_payload_type=distribution_download^EQ
02:37:35.057 - glide.quota.manager - QuotaFinder: > Assigning quota "REST and JSON Catch All" with filter: type=rest^ORtype=json^urlNOT LIKEsysparm_payload_type=edge_encryption_distribution^urlNOT LIKEsysparm_payload_type=machine_learning_download^urlNOT LIKEsysparm_payload_type=distribution_download^EQ to transaction: URL= /api/now/table/redacted, THREAD= API_INT-thread-2, FG= true, TYPE= 7, STATE= 1, USER= magic_user, TIME= 1,118, MEM= 0, ATTRIBUTES= {X-Transaction-Source=Session-Type=non-interactive, user-agent=PostmanRuntime/7.40.0}

02:37:35.057 - glide.quota.manager - QuotaManager: Quota exceeded for "REST Table API request timeout", requesting cancel

 

1 ACCEPTED SOLUTION

NS
Kilo Sage

If anyone comes across the same problem, I asked ServiceNow about it:

Sorry for the delay in responding. I am trying to find a solution that does not require touching the OOTB rules, but it is not possible.

Regarding sys_override:
Like `order, ' the `sys_overrides` field is inherited from sysrule and has different semantics in other tables. It's for Domain Separation. It seems to be especially significant in sys_choice, sys_ui_section, and other application-level metadata.
However, it has no role in the quota manager.

The "order" has little practical consequence: the transaction is canceled based on the "first" rule that it violates, in order, but a non-violated rule coming "before" a violated one doesn't prevent the violation.


Your below assumption is correct. Order or Override will not make a difference here and you will have to end up adjusting the OOTB rules.

 Modifying the OOTB record is the way to go in such case.

View solution in original post

1 REPLY 1

NS
Kilo Sage

If anyone comes across the same problem, I asked ServiceNow about it:

Sorry for the delay in responding. I am trying to find a solution that does not require touching the OOTB rules, but it is not possible.

Regarding sys_override:
Like `order, ' the `sys_overrides` field is inherited from sysrule and has different semantics in other tables. It's for Domain Separation. It seems to be especially significant in sys_choice, sys_ui_section, and other application-level metadata.
However, it has no role in the quota manager.

The "order" has little practical consequence: the transaction is canceled based on the "first" rule that it violates, in order, but a non-violated rule coming "before" a violated one doesn't prevent the violation.


Your below assumption is correct. Order or Override will not make a difference here and you will have to end up adjusting the OOTB rules.

 Modifying the OOTB record is the way to go in such case.