Found the receipt you're talking about, in ledger in @processNymbox, but the Server's Reply transaction says FAILED. about open-transactions HOT 3 OPEN

Here is the inbox.

x@h-desktop ~/.ot $ opentxs --mynym Hiro --server Stampy.com --myacct CDi16VLguwoOYXT2EgwlPVWYOAp8WLPIzLMEs85rT4d inbox

Welcome to Open Transactions -- version 0.93
Using as server: rhp367fVGX9XlHTbfPAlFChZM3pCv2Wgp3R8Ji8Q354
Using as mynym: DjF7kZbp4sqyli4kEE8ZAtRdmrYqOHLM61BKDbhM5ay
Using as myacct: CDi16VLguwoOYXT2EgwlPVWYOAp8WLPIzLMEs85rT4d
Using as mypurse: q4ZH5tVGQgGLHDK6DgWr3LwdJwJrA28RqumW4qHSGir

Show inbox for an asset account (CDi16VLguwoOYXT2EgwlPVWYOAp8WLPIzLMEs85rT4d):
Idx Amt Type Txn# InRef#|User / Acct
---------------------------------|(from or to)
0 -10000 transferReceipt 728 616 |U:aQyZ8wNX54jncs6uh7KwclX5fAdasKiOyCbcDmRO5Dm
|A:VodxQPZC4SCd32yL9h19M8aXXffTtmxIDVcYzqXYy0k
1 -10000 transferReceipt 729 615 |U:aQyZ8wNX54jncs6uh7KwclX5fAdasKiOyCbcDmRO5Dm
|A:VodxQPZC4SCd32yL9h19M8aXXffTtmxIDVcYzqXYy0k
2 -785800 transferReceipt 736 614 |U:aQyZ8wNX54jncs6uh7KwclX5fAdasKiOyCbcDmRO5Dm
|A:VodxQPZC4SCd32yL9h19M8aXXffTtmxIDVcYzqXYy0k

For the above, try: accepttransfers, acceptreceipts, acceptinbox, acceptmoney, or acceptall.
x@h-desktop ~/.ot $

from open-transactions.

The first important part is when it is processing the inbox, and it says this:

Ledger_FinalizeResponse: transferReceipt, trying to 'remove' an issued number (614) that already wasn't on my issued list. (So what is this in my inbox, then? Maybe need to download a fresh copy of it.)

That means somehow there is a receipt for transaction # 614 in your inbox, even though transaction number 614 is apparently NOT signed out to you. (Meaning it's likely an old receipt, which is why OT then automatically tries to download the latest inbox, to make sure it's not operating on an old inbox.)

After it downloads the latest inbox, it tries to process it again, and this time apparently succeeds:

=====>BEGIN Sending getAccountFiles message via ZMQ... Request number: 595
Received server response to getAccountFiles message.

=====>BEGIN Sending processInbox message via ZMQ... Request number: 596
Received server response: @processInbox

HOWEVER, I believe it fails on the processInbox here! I think this is a rare case where a failure log is not present, in the event of failure! I actually looked in the code and there are a couple of possible cases where an error log doesn't appear even in the case of failure, and I believe it might be possible in this case it's happening as a result of transaction that fails because the "reply transaction" from the server isn't present. (See OTClient.cpp line 4299 and notice there is no "else" block with an error message.)

At this point, the OT API believes that it must have gotten out of sync with the server. Is it possible that you replaced the wallet data, without replacing the server data (or vice-versa) ? Because if that's the case, then you definitely have to "resync" from the server, which is a special action that you should otherwise normally never have to do. (If that's the case, you can fix this problem by running the script found at Open-Transactions/scripts/util/resync.ot

If the data wasn't fiddled-with on client or server side, then it's possible (though unlikely) that there is a bug in OT that caused the client and server to go out of sync. Normally OT is very very good about keeping itself in sync, and re-syncing itself when any discrepancies arise. So if indeed there is such a bug, I will want to see if it can be reproduced. (Start with fresh test data and see if the problem happens again. If you can reproduce it, lemme know how and I will try to reproduce it myself.)

Since OT believes it is out of sync, the next thing it tries to do is resync itself:

=====>BEGIN Sending getRequest message via ZMQ... Request number: 1
Received new request number from the server: 597. Updating Nym records...

=====>BEGIN Sending getAccountFiles message via ZMQ... Request number: 597
Received server response to getAccountFiles message.

=====>BEGIN Sending getNymbox message via ZMQ... Request number: 598
Received @getNymbox server response (success)

=====>BEGIN Sending processNymbox message via ZMQ... Request number: 599
Received server response: @processNymbox
Found the receipt you're talking about, in ledger in @processNymbox, but the Server's Reply transaction says FAILED.

You can see it resyncs the request number, which is successful. It grabs the account files again, and it also grabs the nymbox, and tries to process the Nymbox. (OT is trying to make sure there aren't any Nymbox notices that it should be aware of, which it could use to re-sync itself.)

At this point, OT fails trying to process the nymbox, for probably the same reason it fails processing the inbox: because you have to sign a transaction statement to do either of those actions, and that transaction statement has to contain a list of transaction numbers that are signed out to you, and the client and server are probably in disagreement about one of those numbers (most likely 614.)

I would start with fresh data and see if the problem can be reproduced. If it can, I would start raising the log level, and even placing special logs, to try and track it down. If indeed OT is still able to go out of sync (which hasn't happened for over a year) then it would be a bad bug and would require attention.

from open-transactions.

BTW assuming the problem can be reproduced (i.e. it's not a phantom bug or some external data corruption) then I would start asking a series of questions. Such as:

Does the nymfile on the client side show that 614 is issued to that nym?

Does the nymfile on the server side show the same thing?

Do the inboxes on the client and server side both contain the receipt in question? (Could be a download failure.)

from open-transactions.