Fix zero-length byte buffer in InspectedContent

[GaoSSR]

Fix zero-length byte buffer that causes ArrayIndexOutOfBoundsException.

[snicoll]

How does it generate such failure. If it does there should be a test demonstrating that.

[GaoSSR]

Thanks for the feedback! You're right - I've added a test to demonstrate the issue.

The bug: singleByteBuffer was initialized as new byte[0], but write(int b) tries to access singleByteBuffer[0], which throws ArrayIndexOutOfBoundsException.

Why existing tests didn't catch it: All current tests use InputStream or Content as input, which goes through FileCopyUtils.copy(). This uses a byte array buffer and calls write(byte[], int, int) - never write(int b).

The new test:

@Test
void ofWritingSingleByteShouldWork() throws Exception {
    InspectedContent content = InspectedContent.of((outputStream) -> {
        outputStream.write('A');  // This triggers the bug
    });
    assertThat(content.size()).isEqualTo(1);
    assertThat(readBytes(content)).containsExactly('A');
}

This test directly calls write(int) via the IOConsumer<OutputStream> API, which exposes the bug. Without the fix, it fails with:

java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0

With the fix (byte[0] → byte[1]), the test passes.

[GaoSSR]

The CI failure is not related to my code changes.

The error is:

Could not transfer artifact org.apache.maven:maven-settings:jar:3.0 from/to central: Forbidden (403)

This is a Maven Central network issue (403 Forbidden), which commonly happens with GitHub Actions. The failing task generateHelpMojo is in the build-plugin/spring-boot-maven-plugin module, while my changes are in the buildpack/spring-boot-buildpack-platform module - completely unrelated.

I'll push a small change to trigger a CI re-run.

[snicoll]

@GaoSSR thanks for following up. Did you use an agent and ask it to discover a bug for you or were you actually facing a problem related to this code? If that's the former, please stop. Our time is limited and we'd prefer to get contributions based on issues the community actually faces.

[GaoSSR]

Hi @snicoll,

Thanks for asking. No, this was not AI-generated bug hunting. I encountered this ArrayIndexOutOfBoundsException in our production environment when using the InspectedContent.of(IOConsumer) API.

What happened in production:
We have code that writes content byte-by-byte using outputStream.write(int) within the IOConsumer lambda. This triggered the ArrayIndexOutOfBoundsException because singleByteBuffer was initialized as new byte[0].

Why I added the test:
After your initial feedback requesting a test case, I created one that reproduces the exact scenario we hit in production - directly calling write(int) via the IOConsumer API.

The fix is straightforward:
Change byte[0] to byte[1] so the buffer can actually hold the single byte that write(int b) tries to store at index 0.

This is a legitimate production bug. I'm contributing the fix because we're actively using Spring Boot and want to help improve it.

Thanks for maintaining this project.

[GaoSSR]

How dare you?! @snicoll

You used my code fix — changing byte[0] to byte[1] — then closed my PR and committed the code under your own name. You deprived me of the GitHub contributor credit that I deserve!

People like you are a total disgrace to the open-source community!

If you doubted the validity of my code, then why on earth did you merge the fix?!

You’re nothing but a hypocrite, a two-faced liar, and a despicable scoundrel!

[snicoll]

@GaoSSR please calm down, I didn't remove anything, your commit and your contribution is all here: ba94cc4

[snicoll]

Thanks for asking. No, this was not AI-generated bug hunting. I encountered this ArrayIndexOutOfBoundsException in our production environment when using the InspectedContent.of(IOConsumer) API.

OK, cool. Sorry for asking this way but we're getting more and more AI-generated content that we have to triage and with our limited time it has an impact on what we can do.

[GaoSSR]

@snicoll My apologies, I’d like to retract the harsh words I said earlier.

Every time I submit code, I do it with great enthusiasm—these are all my voluntary contributions, driven purely by my passion for the project. But this has been the pattern every single time: you close my PR first, then merge the code in a separate commit afterward.

I don’t ask for anything in return for these contributions; the only small thing I care about is this—you know that a closed PR won’t show up as a merged contribution on my GitHub profile, so I won’t get the corresponding contributor recognition.

I just can’t figure out why you keep closing my PRs before incorporating the code. It really saddens me.

[snicoll]

You keep misunderstanding how this works I am afraid. Your contribution is here, don't worry.

You will also be recognized as a contributor in the announcement of 3.5.10, see the bottom of the 3.5.9 release notes for an example of what I mean.

You know that a closed PR won’t show up as a merged contribution on my GitHub profile, so I won’t get the corresponding contributor recognition.

That is incorrect.

I just can’t figure out why you keep closing my PRs before incorporating the code. It really saddens me.

I am sorry this makes you feel sad. Here's how we work: we clone your contribution in a local branch, polish it if necessary (as in this case) and then do a merge commit with the reference of the PR. This is perfectly valid git behaviour and closed doesn't mean "not merged" at all.

I suppose you can blame GitHub to give you a false impression. I did report our use case to GitHub in the hope they can improve the user experience for the community. I can't share a link as it is private but will update this conversation when I know more.

[GaoSSR]

@snicoll You barely polished my code at all — the only change you made was altering the test case from 1 byte to 3 bytes. I didn’t see any substantial polishing on your part in this case.

What truly upsets me is that you marked my PR as Closed instead of Merged. The commit is indeed preserved in the Git history, but since the GitHub UI labels the PR as "closed" rather than "merged", it makes it seem like my contribution wasn’t properly acknowledged. What’s more, I didn’t get the corresponding contributor badge on my GitHub profile.

As you can see, the contributions I made to Redisson were marked as Merged, which is why they show up as badges on my profile.

Let’s just leave it at that for now. I’m still happy to keep contributing to Spring Boot in the future — after all, it’s a framework I use every single day as a Java developer.

[snicoll]

What truly upsets me is that you marked my PR as Closed instead of Merged.

This has to stop now, I believe I've been more than patient with you. Whether I polish your code or not doesn't change the process, and you can see for yourself that every single PRs in this project are managed this way.

I don't know what badges you are talking about, and I don't care. You should complain to GitHub, not us.

[GaoSSR]

@snicoll Let’s move past this and focus on discussing the code together. I believe our goals have always been aligned! Let’s keep up the great work together in the new year!

[snicoll]

Easy for you to say when you're complaining about things out of our control. In the meantime:

Let's stop this nonsense indeed.

[GaoSSR]

@snicoll Thank you for the explanation and for merging my contribution.