Why is the smb2 oplock lease not broken?

We have a problem with file sharing when processes on several hosts accesses the same file. All hosts are running the same version of Windows 2012 R2. (host A mentioned below is a node in HA Failover Cluster, not sure if that is relevant.) One of our service engineers was able to catch a Wireshark log on when the problem occured. From the logs I can follow the smb2 messages and see that:

1. write_process on host A creates an empty file (smb2 Create Request/Response and Close Request/Reponse exchanged)
2. read_process on host B access the file (smb2 Create Request/Response; create with lease oplock)
3. read_process on host C access the file (smb2 Create Request/Response; create with lease oplock)

At this point hosts B and C has not sent SMB2 close, even though the file has been closed from the code in the read_processes, but the SMB2 close is not sent due to the opportunistic lock. Now write_process on host A want to write to the file but the Create Request immideately gets a NT Status: STATUS_SHARING_VIOLATION (0xc0000043)

The interesting thing is that I can see in the same Wireshark another file access which works as expected:

1. write_process on host A creates an empty file (smb2 Create Request/Response and Close Request/Reponse exchanged)
2. read_process on host C access the file (smb2 Create Request/Response; create with lease oplock)
3. write_process on host A want to access file (smb2 Create Request sent)
4. smb2 lease break message sent to host C
5. host C closes the file
6. write process on host A gets access (smb2 Create Reponse sent to host A)

Before seeing the second, successful, example I had the theory that the problem was that host A accesses the file with no oplock. But I would now rule out that theory.

This is how the create request from host A looks like:

Frame 14521: 416 bytes on wire (3328 bits), 416 bytes captured (3328 bits) on interface 6
Null/Loopback
Internet Protocol Version 4, Src: <ip A>, Dst: <ip D>
Transmission Control Protocol, Src Port: 50198, Dst Port: 445, Seq: 3973846, Ack: 68498, Len: 372
NetBIOS Session Service
SMB2 (Server Message Block Protocol version 2)
    SMB2 Header
        Server Component: SMB2
        Header Length: 64
        Credit Charge: 1
        Channel Sequence: 0
        Reserved: 0000
        Command: Create (5)
        Credits requested: 1536
        Flags: 0x00000008, Signing
        Chain Offset: 0x00000000
        Message ID: Unknown (811455)
        Process Id: 0x0000feff
        Tree Id: 0x001c0025  <share name>
        Session Id: 0x0008500d64000069
        Signature: a8ac43ccf4b4d59f2fb9b930ea01c421
        [Response in: 14523]
    Create Request (0x05)
        StructureSize: 0x0039
        Oplock: No oplock (0x00)
        Impersonation level: Impersonation (2)
        Create Flags: 0x0000000000000000
        Reserved: 0000000000000000
        Access Mask: 0x00120089
        File Attributes: 0x00000080
        Share Access: 0x00000003, Read, Write
        Disposition: Create (if file exists fail, else create it) (2)
        Create Options: 0x00000060
        Filename: <filename>
        ExtraInfo SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 SMB2_CREATE_QUERY_MAXIMAL_ACCESS_REQUEST SMB2_CREATE_QUERY_ON_DISK_ID

The create request from host C look like this:

Frame 16263: 502 bytes on wire (4016 bits), 502 bytes captured (4016 bits) on interface 0
Ethernet II, Src: Cisco_a5:07:01 (00:24:14:a5:07:01), Dst: HewlettP_7a:d4:58 (14:02:ec:7a:d4:58)
Internet Protocol Version 4, Src: <ip C>, Dst: <ip D>
Transmission Control Protocol, Src Port: 51747, Dst Port: 445, Seq: 29594, Ack: 5030645, Len: 448
NetBIOS Session Service
SMB2 (Server Message Block Protocol version 2)
    SMB2 Header
        Server Component: SMB2
        Header Length: 64
        Credit Charge: 1
        Channel Sequence: 0
        Reserved: 0000
        Command: Create (5)
        Credits requested: 0
        Flags: 0x00000008, Signing
        Chain Offset: 0x00000000
        Message ID: Unknown (2340656)
        Process Id: 0x0000feff
        Tree Id: 0x001c0029  <share name>
        Session Id: 0x0008500b7c000d81
        Signature: ff6476de30378d5fbba4f438c2168510
        [Response in: 16304]
    Create Request (0x05)
        StructureSize: 0x0039
        Oplock: Lease (0xff)
        Impersonation level: Anonymous (0)
        Create Flags: 0x0000000000000000
        Reserved: 0000000000000000
        Access Mask: 0x00120089
        File Attributes: 0x00000000
        Share Access: 0x00000005, Read, Delete
        Disposition: Open (if file exists open it, else fail) (1)
        Create Options: 0x00400060
        Filename: <filename>
            Offset: 0x00000078
            Length: 140
        ExtraInfo SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 SMB2_CREATE_QUERY_MAXIMAL_ACCESS_REQUEST SMB2_CREATE_QUERY_ON_DISK_ID SMB2_CREATE_REQUEST_LEASE
            Offset: 0x00000108
            Length: 180
            Chain Element: SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 "DH2Q"
            Chain Element: SMB2_CREATE_QUERY_MAXIMAL_ACCESS_REQUEST "MxAc"
            Chain Element: SMB2_CREATE_QUERY_ON_DISK_ID "QFid"
            Chain Element: SMB2_CREATE_REQUEST_LEASE "RqLs"

Any idea why the breaking of the oplock works in one case but not on another?