[Bug] v0.40.1 - "graphman reassign" operations fails ~ 50% of the time without any meaningful info in subgraph's logs

Bug report

Hi Team,
I'm using grapnode v0.40.1. Roughly 50% of my "graphman reassign" operations look like below:

1. Subgraph is running perfectly fine (healthy, no lag, not paused) on indexer node X
2. I invoke "graphman reassign SUBGRAPH_HASH indexer_node_Y" command and it finalises without problems
3. I check the status of the subgraph with "graphman info --status" command after few minutes and the subgraph is stuck, it isn't processing any new blocks
4. Target index node doesn't produce logs for this subgraph
5. Prometheus metrics (for example "deployment_head") are available on the previous index node and on the new/target indexer node, on the previous index node they have misleading values as processing doesn't really take place on it anymore
6. I have to perform at least 1 more reassign operation to fix the subgraphs, sometimes up to 5 reassignment operations have to be done
   I checked existing issues and it may be the case that https://github.com/graphprotocol/graph-node/issues/5253 is related so I've added a comment to it.

Can someone please take a look?

Relevant log output

IPFS hash

No response

Subgraph name or link to explorer

No response

Some information to help us out

• Tick this box if this bug is caused by a regression found in the latest release.
• Tick this box if this bug is specific to the hosted service.
• I have searched the issue tracker to make sure this issue is not a duplicate.

OS information

None

Beginne damit, den intermittierenden graphman reassign SUBGRAPH_HASH indexer_node_Y-Workflow zu reproduzieren, und untersuche anschließend graphman info --status. Vergleiche dabei die Logs und deployment_head auf beiden Indexer-Knoten. Sieh dir das verwandte Issue #5253 als Kontext an. Als erledigt gilt die Aufgabe, wenn die Neuzuweisung auf dem Zielknoten konsistent mit der Verarbeitung beginnt und bei Fehlern genaue Metriken und nützliche Logs vorhanden sind.