Potential bug in evaluationTimeout when using auth?

When i use g.with("evaluationTimeout", X).call(<some call step).next() without authentication it works. When I do it with authentication enabled it does not work. The offending code appears to be this piece of TraversalOpProcessor.java
final long seto = args.containsKey(Tokens.ARGS_EVAL_TIMEOUT) ?
((Number) args.get(Tokens.ARGS_EVAL_TIMEOUT)).longValue() : context.getSettings().getEvaluationTimeout();
final long seto = args.containsKey(Tokens.ARGS_EVAL_TIMEOUT) ?
((Number) args.get(Tokens.ARGS_EVAL_TIMEOUT)).longValue() : context.getSettings().getEvaluationTimeout();
Which returns properly without authentication enabled as args contains "evaluationTimeout", but when authentication is enabled, that key does not exist, and instead it is embedded deeper down (see attached pic, it's in configuration of the OptionsStrategy deep down) Has anyone seen this issue before?
No description
Solution:
The problem appears to be in this block of code
Jump to solution
5 Replies
Lyndon
LyndonOP6mo ago
Pic of no auth exact same query for reference
No description
Lyndon
LyndonOP6mo ago
Seems like call step piece of it is irrelevant. With authentication enabled, even g.with("evaluationTimeout", X).V().next() doesnt properly set the evaluationTimeout
Solution
Lyndon
Lyndon6mo ago
The problem appears to be in this block of code
Lyndon
LyndonOP6mo ago
No description
Lyndon
LyndonOP6mo ago
The incoming requestMessage has "evaluationTimeout" as a top level argument which is not copied though you could say that the check later on should drill into the optiosn to look for it
Want results from more Discord servers?
Add your server