How to test persistent ledger entry archival | Stellar Developers | Page 1

bright kettle Mar 25, 2026, 4:13 PM

#

I have some logic like this that I want to test

assert!(get_persistent_entry(), 2);
    pub const LEDGERS_PER_DAY: u32 = (24 * 3600) / 5;
    pub const MAX_TTL: u32 = 365 * LEDGERS_PER_DAY;
    env.ledger().with_mut(|li| {
        li.sequence_number += (MAX_TTL);
    });
assert!(get_persistent_entry(), 2);

I want it to panic/error and not restore the entry, for now nothing happens, how do I test this?

#

?

#

Could you answer the question in the thread? so that all future developers may find the answer

ashen shuttle Mar 25, 2026, 4:16 PM

#

you don't really need to test this. it is not a part of your contract logic and not even a part of the soroban host environment. it is pointless to test this

bright kettle Mar 25, 2026, 4:16 PM

#

Yes I know, but is there a way to test this?

#

I know that the tx would fail if it's not restored and that restoration is implicit and done in tx construction

ashen shuttle Mar 25, 2026, 4:17 PM

#

soroban host does provide the best effort emulation of what happens in reality. since most of the time the entry will just get auto-restored, environment emulates auto-restoration.

ashen shuttle Mar 25, 2026, 4:17 PM

#

bright kettle Yes I know, but is there a way to test this?

again, you don't really need to test this

bright kettle Mar 25, 2026, 4:17 PM

#

Right, I understand, I accept that answer. But is there a way to test this, I was just curious, I assume not

ashen shuttle Mar 25, 2026, 4:18 PM

#

it will not provide any test coverage. the same way you don't need to test the fact that e.g. fee will be withdrawn from transaction. this is logic external to your contract.

bright kettle Mar 25, 2026, 4:18 PM

#

I totally agree

ashen shuttle Mar 25, 2026, 4:18 PM

#

and yeah, as I mentioned the current emulation behavior is that we emulate auto-restoration, not failure

bright kettle Mar 25, 2026, 4:19 PM

#

So there is never a situation when you try to get an archived entry that is not temporary and the getter returns None

#

either the TX fails because it isn't restored

#

or if it is restored you get the actual value there

#

as stated in the docs

ashen shuttle Mar 25, 2026, 4:20 PM

#

to be clear, we could emulate the failure, but this will still be emulation, so it's hard to say that you 'tested' it. so it's basically not possible to test the actual behavior within the SDK tests. it is only possible to observe the full e2e behavior in a network (e.g. a local network with quickstart)

bright kettle Mar 25, 2026, 4:20 PM

#

If you build a transaction manually without running simulation (and therefore don’t include all needed archived entries in the restore list), automatic restoration will not occur and the transaction will fail when it tries to access those archived entries.

ashen shuttle Mar 25, 2026, 4:20 PM

#

yes, exactly

bright kettle Mar 25, 2026, 4:20 PM

#

I always just like to test certain things in docs, so I was just trying to test it even though I know

#

that is what the docs say

#

but sometimes it's good to try to ascertain that it really is that way

#

but here the only way would be to spin up a node

ashen shuttle Mar 25, 2026, 4:21 PM

#

basically your contract will never be invoked with archived data. which is why it's tricky to observe in tests, because tests by definition enter your contract

bright kettle Mar 25, 2026, 4:22 PM

#

I understand, you don't need to explain to me, I totally understand

ashen shuttle Mar 25, 2026, 4:22 PM

#

so we can only do our best effort at emulation, and you're right, the only way to observe the 'true' behavior is spinning up a network

bright kettle Mar 25, 2026, 4:22 PM

#

I was just paranoia testing

#How to test persistent ledger entry archival