chain reorganization – Transaction incorrect when studying a block from `blk*.dat` information

The issue happens with block 1,669,774 on testnet (https://blockstream.information/testnet/block/0000000010001cebd3e4f2fe5f2e2cbbe35ba6457554d9e0e6eb100b6f91eaee).

To acquire a block I retrieve the file and the place by studying the important thing b<block_hash> from the leveldb database and I then parse the block within the normal means. This works effectively for all blocks besides this one which returns me the listing of transactions for this block BEFORE the reorganization.

For instance the listing of transactions comprises the hash 6ef0f0d3fcf20aedefa37425ea93e69c7da4d04fd1ce983c5cba613630e775ca as a substitute of the hash f07b4eb879ead12e58742e322878310d4b5bcd48b25c1e4ab781 672a9f44a312.
bitcoin-cli getblock <hash> returns me the proper listing of transactions. (after all I exploit the proper hash in each instances 0000000010001cebd3e4f2fe5f2e2cbbe35ba6457554d9e0e6eb100b6f91eaee).

The best way to get hold of the proper model of the block?
Thanks prematurely!

Edit:
Right here the perform I exploit to get the file and the place:

def read_raw_block(self, block_hash, only_header=False):
        block_key = bytes('b', 'utf-8') + binascii.unhexlify(inverse_hash(block_hash))
        block_data = self.blocks_leveldb.get(block_key)
        ds = BCDataStream()
        ds.write(block_data)

        model = ds.read_var_int()
        peak = ds.read_var_int()
        standing = ds.read_var_int()
        tx_count = ds.read_var_int()
        file_num = ds.read_var_int()
        block_pos_in_file = ds.read_var_int() - 8
        block_undo_pos_in_file = ds.read_var_int()
        block_header = ds.read_bytes(80)
        self.prepare_data_stream(file_num, block_pos_in_file)
        block = self.read_block(self.data_stream, only_header=only_header)
        block['block_index'] = peak
        return block

SOLVED:
it is a segwit transaction, f07b4eb879ead12e58742e322878310d4b5bcd48b25c1e4ab781672a9f44a312 is the txid and 6ef0f0d3fcf20aedefa37425ea93e69c7da4d04fd1ce983c5cba613630e775ca it is the hash!