Resend phase send the corrupted/missing fields version of the sent message

[HoanqDucAnh]

Describe the bug
The application enters a state where the FileStore is used and normal, had the right version of the sent Fix message in the .body file. Subsequently, when a ResendRequest is received (e.g., after a brief network disconnect/reconnect), the engine attempts to retrieve messages from this corrupted store. It fails to read the body content correctly but does not raise an exception. Instead, it constructs and sends malformed messages that have valid headers (SeqNum, MsgType) but are missing mandatory body fields (Symbol, Side, OrderQty, etc.).

To Reproduce
This behavior is not consistent, it just happened once i havent able to encouter it again

1. Configure QuickFIX/J to use FileStore with high-throughput message traffic.
2. Run the primary FIX application continuously under load.
3. Stop the primary and we turn on our backup FIX that had no previous messages from the primary FIX server
4. The backup send resend request and also new order at the same time
5. The acceptor resend and then disconnect then reconnect and require to resend the older FIX order
6. The application re-sent corrupted fix order

Expected behavior
The application should resend the correct version of the fix order in the .body

system information:

• OS: Ubuntu 24.04
• Java version JDK8
• QFJ Version 2.3.1

Additional context
.body file (i'll be focusing on the msg sequence 25383 & it's really looks like that on the same row)

8=FIX.4.4�9=62�35=5�34=25380�49=***�52=20251121-06:21:51.179�56=***�10=144�8=FIX.4.4�9=122�35=A�34=25381�49=***�52=20251121-06:22:01.006�56=***�98=0�108=30�553=***�554=***�10=240�8=FIX.4.4�9=71�35=2�34=25382�49=***�52=20251121-06:22:01.150�56=***�7=1�16=0�10=251�8=FIX.4.4�9=261�35=D�34=25383�49=***�52=20251121-06:22:01.288�56=***�1=066C000415�11=7953378�21=1�38=100�40=2�43=N�44=49000�50=00661�54=1�55=VN000000VCS8�59=0�60=20250908-13:18:49�75=20250908�97=N�128=STX�129=G1�421=704�544=1�581=1�20000=8000�20054=00�20063=0�20064=0�10=044�

my log:

21/11/2025 06:23:03(Milis=1763706183038):onLogon>FIX.4.4:***->***
21/11/2025 06:23:03(Milis=1763706183038):Received logon
21/11/2025 06:23:03(Milis=1763706183062):fromAdmin>8=FIX.4.4�9=81�35=2�34=30207�43=N�49=***�52=20251121-06:21:47�56=***�97=N�7=25380�16=0�10=249�
21/11/2025 06:23:03(Milis=1763706183109):toApp>8=FIX.4.4�9=134�35=D�34=25383�43=Y�49=***�52=20251121-06:23:03.109�56=***�122=20251121-06:22:01.288�1=066C000415�11=7953378�21=1�38=100�40=2�10=055�
21/11/2025 06:23:03(Milis=1763706183110):toAdmin>8=FIX.4.4�9=108�35=4�34=25380�43=Y�49=***�52=20251121-06:23:03.109�56=***�122=20251121-06:23:03.109�36=25383�123=Y�10=135�
21/11/2025 06:23:03(Milis=1763706183110):toApp>8=FIX.4.4�9=134�35=D�34=25384�43=Y�49=***�52=20251121-06:23:03.110�56=***�122=20251121-06:22:01.288�1=066C000415�11=7953379�21=1�38=100�40=2�10=049�
# The other 3000+ order message is corrupted the same as 25383 & 25384

[chrjohn]

I try to make sense of this. How did the filestore get corrupted in the first place? Did you access it concurrently?
However, if it is corrupted there is no way to correct it "automatically".
Will check the code and come back to you.