// Set incorrect structure size (should be 65)
        SMBUtil.writeInt2(64, malformedBuffer, 0);

        SMBProtocolDecodingException exception = assertThrows(SMBProtocolDecodingException.class, () -> {
            response.readBytesWireFormat(malformedBuffer, 0);
        });

        assertTrue(exception.getMessage().contains("Structure size is not 65"));
        assertTrue(exception.getMessage().contains("got: 64"));

                SmbConstants.O_CREAT | SmbConstants.O_WRONLY | SmbConstants.O_TRUNC, SmbConstants.FILE_WRITE_DATA,
                SmbConstants.DEFAULT_SHARING);

        // When
        outputStream.write(65); // Write 'A'

        // Then
        verify(mockTreeHandle, atLeastOnce()).send(any(Smb2WriteRequest.class), any());
    }

    @Test
    void testWriteByteArray() throws IOException, CIFSException {

        setReceivedMethod.invoke(resp);
    }

    private byte[] createValidNegotiateResponseBuffer() {
        byte[] buffer = new byte[256];
        int offset = 0;

        // Structure size (65)
        SMBUtil.writeInt2(65, buffer, offset);

        // Security mode
        SMBUtil.writeInt2(Smb2Constants.SMB2_NEGOTIATE_SIGNING_REQUIRED, buffer, offset + 2);

        // Dialect revision

        if (buffer == null || buffer.length < bufferIndex + 65) {
            throw new SMBProtocolDecodingException("Buffer too small for SMB2 negotiate response (minimum 65 bytes required)");
        }

        final int structureSize = SMBUtil.readInt2(buffer, bufferIndex);
        if (structureSize != 65) {
            throw new SMBProtocolDecodingException("Structure size is not 65, got: " + structureSize);
        }

   * Arrays are a mess from a nullness perspective, and Class instances for object-array types are
   * even worse. For now, we just suppress and move on with our lives.
   *
   * - https://github.com/jspecify/jspecify/issues/65
   *
   * - https://github.com/jspecify/jdk/commit/71d826792b8c7ef95d492c50a274deab938f2552
   */
  /*
   * TODO(cpovirk): Is the unchecked cast avoidable? Would System.arraycopy be similarly fast (if

   * Arrays are a mess from a nullness perspective, and Class instances for object-array types are
   * even worse. For now, we just suppress and move on with our lives.
   *
   * - https://github.com/jspecify/jspecify/issues/65
   *
   * - https://github.com/jspecify/jdk/commit/71d826792b8c7ef95d492c50a274deab938f2552
   */
  /*
   * TODO(cpovirk): Is the unchecked cast avoidable? Would System.arraycopy be similarly fast (if

        A = GG(A, B, C, D, X[1], 3);
        D = GG(D, A, B, C, X[5], 5);
        C = GG(C, D, A, B, X[9], 9);
        B = GG(B, C, D, A, X[13], 13);
        A = GG(A, B, C, D, X[2], 3);
        D = GG(D, A, B, C, X[6], 5);
        C = GG(C, D, A, B, X[10], 9);
        B = GG(B, C, D, A, X[14], 13);
        A = GG(A, B, C, D, X[3], 3);
        D = GG(D, A, B, C, X[7], 5);
        C = GG(C, D, A, B, X[11], 9);

        src[srcIndex + 16] = 0x00; // hex code
        src[srcIndex + 17] = (byte) 0xFE; // All flags except one: 11111110
        // Bit 7: group (1)
        // Bits 6-5: owner node type (11 = 3)
        // Bit 4: being deleted (1)
        // Bit 3: in conflict (1)
        // Bit 2: active (1)
        // Bit 1: permanent (1)

        // MAC address

We can do the same as before to **read** `Hero`s, again, we use `response_model=list[HeroPublic]` to ensure that the data is validated and serialized correctly.

{* ../../docs_src/sql_databases/tutorial002_an_py310.py ln[65:72] hl[65] *}

### Read One Hero with `HeroPublic` { #read-one-hero-with-heropublic }

We can **read** a single hero:

{* ../../docs_src/sql_databases/tutorial002_an_py310.py ln[75:80] hl[77] *}

              }
            ]
          }
        ]
      },
      "gridPos": {
        "h": 6,
        "w": 6,
        "x": 12,
        "y": 12
      },
      "id": 65,
      "options": {
        "legend": {
          "calcs": [],
          "displayMode": "list",
          "placement": "bottom",
          "showLegend": true
        },
        "tooltip": {