bug: `Authorizer::run()` behaves the same for `Authorizer::authorize()` and `Authorizer::authorize_with_limits()` when it should not

[georglauterbach]

When not using .set_limits() on an AuthorizerBuilder, the default limits are used. When you set limits with .set_limits(), they are properly set on self (obviously).

biscuit-rust/biscuit-auth/src/token/builder/authorizer.rs

Lines 264 to 267 in 27ef8e3

	pub fn set_limits(mut self, limits: AuthorizerLimits) -> Self {
	self.limits = limits;
	self
	}

This works well with Authorizer::authorize because all limits are properly set beforehand:

biscuit-rust/biscuit-auth/src/token/authorizer.rs

Lines 365 to 375 in 27ef8e3

	pub fn authorize(&mut self) -> Result<usize, error::Token> {
	let execution_time = self.run()?;
	let mut limits = self.limits.clone();
	limits.max_iterations -= self.world.iterations;
	if execution_time >= limits.max_time {
	return Err(error::Token::RunLimit(error::RunLimit::Timeout));
	}
	limits.max_time -= execution_time;
	self.authorize_with_limits(limits)
	}

And the call to self.run() uses the limits from self properly.

---

Now, when I use Authorizer::authorize_with_limits, the call to self.run() does not propagate these limits as run does not take any limits:

biscuit-rust/biscuit-auth/src/token/authorizer.rs

Lines 42 to 54 in 27ef8e3

	pub fn run(&mut self) -> Result<Duration, error::Token> {
	match self.execution_time {
	Some(execution_time) => Ok(execution_time),
	None => {
	let start = Instant::now();
	self.world
	.run_with_limits(&self.symbols, self.limits.clone())?;
	let execution_time = start.elapsed();
	self.execution_time = Some(execution_time);
	Ok(execution_time)
	}
	}
	}

Hence, the limits from self are used - which are not the limits we explicitly provided when calling authorize_with_limits():

biscuit-rust/biscuit-auth/src/token/authorizer.rs

Line 48 in 27ef8e3

.run_with_limits(&self.symbols, self.limits.clone())?;

---

This left me with weird test failures because authorize_with_limits() does not propagate the limits properly to run().

[divarvel]

Good catch, and thanks for the analysis! #313 should fix it.

I’ll check if I can add tests that pin this behaviour

[georglauterbach]

Thanks for tackling this so fast!