Memoize for a duration based on the memoized item

[scrocquesel]

I am caching http response and would like to invalidate based on the content of the response but the BooleanSupplier is not fed with the item.

More precisely, i'm fetching a JWT token and an access token response is providing a "expires_in" value. I'm trying to make the memoize honor this value.

Ideally, something like

Uni.createFrom().item(new AccessTokenResponse())
    .memoize().atLeast(item -> item.getExpiresIn())

or

Uni.createFrom().item(new AccessTokenResponse())
    .memoize().until(item -> item.getExpiresIn() + item.getGeneratedAt() < System.nanoTime())

Is it something possible ?

[heubeck]

Fun fact: Exactly your case let to the memoize operator, that's there today ;)
For the full story have a look to this issue and the linked PRs: #231

There were implementation but also design reasons that made it quite challenging to invalidate based on checks on the cached item.

My solution (up to now) was to have an validation on the jwt before consuming it, thowing some kind of expiry exception that cases a retry of the whole pipeline (that starts with requesting a fresh jwt).

But some time has passed by, I'm really curious, if there might be a solution in your sense possible.

[jponge]

Now I think I did not pass the current memoized value for evaluation because of race conditions, but perhaps we could have another look.

Is anyone here interested in exploring / doing a PR? 😉

[scrocquesel]

@heubeck Interested in your chain call. Right now, I don't know how I can go back to before the memoize in case of a failure.

[heubeck]

sure... I must admit, I missed an important detail (suppressed by brain :P) - there's external state used for .until()

// both fields are application scoped, may need to be static in different context.
private final Uni<OmikronToken> tokenUni;
private final AtomicBoolean refreshToken = new AtomicBoolean(false); 

// (...)

tokenUni = config.getWebClient().post(config.getTokenPath())
            .putHeader(HttpHeaders.CONTENT_TYPE.toString(), "application/x-www-form-urlencoded")
            .putHeader(HttpHeaders.ACCEPT.toString(), APPLICATION_JSON)
            .sendBuffer(Buffer.buffer(formData)) // formData contains credentials
            .ifNoItem().after(config.getTokenTimeout()).fail()
            .flatMap(response -> {
                if (response.statusCode() == 200) {
                    var token = response.bodyAsJson(OmikronToken.class);
                    LOG.info("Token received, valid until {}", token.getExpiration());
                    return Uni.createFrom().item(token);
                } else {
                    LOG.error("Token request failed with status {}: {}", response.statusCode(), response.bodyAsString());
                    return Uni.createFrom().failure(new IllegalStateException("Failed to receive token"));
                }
            })
            .memoize().until(() -> refreshToken.get())
            .onItemOrFailure().invoke((token, failure) -> {
                var invalidateToken = failure != null || token.isExpired();
                refreshToken.set(invalidateToken);
                if (invalidateToken) {
                    // as the token is already invalid, we trigger a refresh cycle
                    throw new FetchTokenRetry();
                }
            })
            .onFailure(FetchTokenRetry.class).retry().atMost(1);

created this more than a year ago, haven't checked for Mutiny API updates to make it (even more) nice.

Happy to hear your thoughts - maybe Julien can guide us to a more Mutiny-native solution.

[scrocquesel]

@heubeck Thanks. I'll try to make the field instance scoped because the app can get token for multiple config.

@jponge I think the same apply with retry which cannot be configured depending the last item value either.

[jponge]

@scrocquesel feel free to open issues, we can have API discussions around these observations. It's best if you can have a small minimal snippet for each idea.