From the aepps site
Yet from my server i see 5 transactions on the same block, what is going on?
I would guess there was a micro-fork at the end of the previous generation and that these nodes (are they both middleware nodes?) do some caching or something that goes wrong in that case?
idk if the first one is a middleware node, second one is a mdw+proxy, but the response for that endpoint is the node response, here is the unproxied response, but the quesiton remains, why is the official endpoint, the one used by the official explorer, have this inconsistency? and where is the underlying issue? is it in the middleware? is it in the node?
I just spent a couple of hours trying to find the problem and it turns out because my key is actually the hash i couldn’t insert a transaction because it existed, but when i cleared that block I didn’t clear the duplicated transaction because at that point in time it was in the previous block.
I know i will be adding checks so if this happens (a transaction gets inserted with a different block number) I will force refresh the records in the middleware.
But i remember the official middleware had a double verification of the blocks (one on top and one delayed, precisely to prevent forking)
So I am bringing this up to see where the problem is 
The first one is also a Middleware node - I checked (Thinking of it the mdw in the address is probably a hint )
A standard node seems to be returning the correct thing: http://54.214.159.45:3013/v2/micro-blocks/hash/mh_thmVtbYwit4eUdDU28V4YpYjajQ5FLj8xQxNSere8CBXecmgb/transactions
So it does look like a problem with the middleware/caching that should probably be looked into.
I will look into this–thanks for the heads up.
j
@hanssv.chain well, in my experience names and what is really installed is not always the same, so I would rather check and not assume that.
@jsnewby Great 
OK so this is an issue with updating the micro block which a transaction is associated with, but forgetting to update the block_height to the new one. It’s easy to detect and fix in the DB, which I’ve done, and the code is trivial to fix. Thanks for the report.
2 Likes
This SQL fixes the DB, by the way:
update transactions t set block_height = k.height from key_blocks k, micro_blocks m where t.micro_block_id=m.id and m.key_block_id=k.id and t.block_height <> k.height;
I have mase it run every minute on the mdw box, until the fix is released.