ERROR: CTxMemPool::ReadFeeEstimates() on komodod start up

[komodoplatform]

ERROR: CTxMemPool::ReadFeeEstimates() on komodod start up

[dimxy]

is it okay to fail reading this file once? If yes we may just set nVersionRequired to 70100 on writing and instruct users to ignore the error one time at startup

[jmjatlanta]

The logic within ReadFeeEstimates seems to be there to protect the code from reading "older" versions. And to the code, a lower number is an older version.

Changing nVersionRequired in ReadFeeEstimates disables the "version protection" feature of the function, so I imagine that is not what you were suggesting.

Changing nVersionRequired in WriteFeeEstimates would fix this issue for new clients, but would not solve the problem for clients that had the previous version. The error would still appear. In addition, the "version protection" would not work as intended for versions between 70100 and 109900. I do not know the history of those version numbers, so am unsure if that is a real problem or not (I am guessing not).

Other possible options:

1. Fix CLIENT_VERSION to something above 109900 (logical)
2. Add logic that specifically looks for 109900 and "does the right thing" (yuck)
3. change nVersionRequired as you suggested and deal with the error message, making sure each run of komodod writes the file so that the error only appears once, only after the "upgrade". (the lazy but tolerable fix)

Update: I have verified that the fee estimate file is written on komodod shutdown, so with option 3, the error will only appear once if komodod shuts down properly.

Sample test: https://github.com/KomodoPlatform/komodo/compare/dev...jmjatlanta:jmj_issue_523?expand=1

[dimxy]

I agree that much better is to provide compatibility with the files written with the 109900 value
maybe we could make a special case for it:
from now on write with nVersionRequired == 70100
but allow also to read old files with 109900:

        filein >> nVersionRequired >> nVersionThatWrote;
        if (nVersionRequired > CLIENT_VERSION && nVersionRequired != 109900 /*allow old files*/)
            return error("CTxMemPool::ReadFeeEstimates(): up-version (%d) fee estimate file", nVersionRequired);

assuming the format has never changed in our codebase. So we establish protection for future versions

[DeckerSU]

My offer is to change version required to read in WriteFeeEstimates to 70100, like:

bool
CTxMemPool::WriteFeeEstimates(CAutoFile& fileout) const
{
    try {
        LOCK(cs);
        fileout << 70100; // version required to read: 0.7.1.0 or later

And users with existing fee_estimates.dat who will have the:

ERROR: CTxMemPool::ReadFeeEstimates(): up-version (109900) fee estimate file

should just delete the file and let the app re-create it.

[dimxy]

Even no need to delete the file. The error would show once on the first startup and the file will be overwritten on next write.
But maybe we need to provide that the error won't show itself and the file is read okay even at the first run ?

[DeckerSU]

Maybe. But i just don't like "special cases". What if we will add 109900 as an exception, but in future the format of this file will be changed and this exception will cause unforeseen consequences? I always vote for clean logic without "special cases" and "workaround of workarounds". Value of 109900 obviously was a mistake / oversight during version changing, so, i vote for totally get get rid of it, instead of turn it into exception.

[jmjatlanta]

Even no need to delete the file. The error would show once on the first startup and the file will be overwritten on next write. But maybe we need to provide that the error won't show itself and the file is read okay even at the first run ?

What about changing ERROR: to Warning: and perhaps changing the verbiage to denote that processing will continue (as does a nearby message)?

[dimxy]

Maybe let's add a small PR with a fix like this DeckerSU/KomodoOcean@eccb8f7 to close this issue too