You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[FIXED] workqueue reset to 0 when blk file is zero-sized due to unflushed data on crash (#6882)
I encountered an issue where a Workqueue stream’s first and last
sequence numbers were unexpectedly reset to 0 following an abrupt
termination of the NATS server. Interestingly, the consumer remained
fully caught up with messages and retained its expected state even after
the crash, but the stream itself appeared to have been reset.
I was able to retrieve a backup of the data after the crash and debug it
locally. During analysis, I found that new msgs had not been flushed to
disk, resulting in a zero-sized blk file I believe. As a result, during
recovery, the stream state remained at zero and the index.db could not
be used to reconstruct the state
Resolves : #6881
Signed-off-by: souravagrawal <souravagrawal1111@gmail.com>
fs, err=newFileStoreWithCreated(fs.fcfg, cfg, time.Now(), prf(&fs.fcfg), nil) //Expire all messages so stream does not hold any message, this is to simulate consumer consuming all messages.
9576
+
require_NoError(t, err)
9577
+
require_NoError(t, fs.Stop()) //To Ensure there is a state file created
9578
+
require_True(t, len(fs.blks) ==1) //Since all messages are expire there should be only 1 blk file exist
9579
+
os.Remove(fs.blks[0].mfn) // we can change it to have a consumer and consumer all messages too, but removing blk files will simulate same behavior
9580
+
9581
+
//Now at this point stream has only index.db file and no blk files as all are deleted. previously it used to reset the stream state to 0
9582
+
// now it will use index.db to populate stream state if could not be recovered from blk files.
0 commit comments