Weird interaction between moka and xmlrpc

This is so annoying to track down. I had everything working with the cache until deeper integration testing. When calling a remote server (routines tested) via the xmlrpc crate, my moka cache now gets reset.

Yeah, I know.

It's completely reproducible at this step:

pub fn call<T: Transport>(&self, transport: T) -> Result<Value, Error> {
    let mut reader = transport

The further I dig into this, the more obvious it becomes I'll have to implement a workaround.
What's the best way to save a moka cache? clone? I'm also going to try locking it across the xmlrpc call.

Problem solved thanks to the excellent help from the moka developer. I misunderstood how to implement the Expiry trait!

It's not lazy_static. It's the expire_after() implementation. Back to moka.

It's looking like this is a lazy_static issue. Since it's being deprecated, I've switched the cache to once_cell. Seems to be working.

I'm wondering if this is an issue with lazy_static getting cought up in finding stuff to drop. I see lazy_static is deprecated. I'd rather spend time rewriting to accomodate lazy_static deprecation than try to work around loss of the Expiry trait in mini-moka.

Works with mini-moka, but I don't get the Expiry trait. I'm opening an issue w/ moka-rs

cache won't work as the cached value also gets smashed.
If I had to guess, I'd say it's a curl memory managment issue via Easy trait. Definitely not addressable by mere mortals. It shows up as posted earlier because the debug trace is not in real time. When I see the debugger stop at the let, a subsequent drop (not shown) as part of curl has already executed and smashed the cache.

This is really annoying. I've wasted a lot of time on designing unit tests for this architecture only to find it spectacularly fall over when trying to integrate crates.

Except when it collapses in a heap by the side of the road refusing to budge, it's a powerful sports car that can respond with elegance and speed.