If "grace" is shorter than ttl, and "grace" period has gone by, ttl is ignored.

[renglish-rs]

I'm hoping that I'm just crazy on this one, but I'd love some input!

In my testing, if I set to the cache with;

.getOrSet({
  key: 'testing_key',
  ttl: '60s',
  grace: '60s',
  factory: () => { 
    console.log(`I've been hit`);
    return 'Hello World';
  }
});

And then wait 61s, the log "I've been hit" will be logged, as the factory is called again.
The documentation on grace periods leads me to believe this is a bug, as it says:

Grace periods allow cached data to be served for an extended time after their expiration

Curiously enough, if I also do;

.getOrSet({
  key: 'testing_key',
  ttl: '60s',
  grace: '1s',
  factory: () => { 
    console.log(`I've been hit again`);
    return 'Hello World';
  }
});

And then wait a total of 2s, the log "I've been hit again" will be logged.
I would expect to at least wait out the TTL before the factory is called again, regardless of the grace.

If this is intentional, maybe it'd be a good idea to note it somewhere in the documentation?

I've tried 1.5.0, 1.5.1, and 1.6.0 (Which isn't listed in this github, but is on npm)

[osseonews]

The entire grace period thing is extremely confusing. From my tests, per your comment, the grace period has to be greater than the TTL or else it is useless. Basically, the TTL is the logical expiration that is set by the code, and the grace period is an actual TTL. So for example in Redis the key will expire in Redis itself based on the grace, but there is a logical expiration value in the Redis key that Bento cache will use to fetch a new value from the cache before actual expiration. So logically there is no point in setting a Grace to be less than the TTL, because then the cache will have already expired, before you can even use logical expiration.