Workflow [PR], commit [389d969]

Summary: ❌

@antaljanosbenjamin perhaps for review?

Based on this comment, it is not clear to me if this is always a good thing. However, I assume that is solved in the meantime. If not, we can always revert the PR. There is one thing though: could you please add your patch to the file in our fork of librdkafka where we describe what needs to be applied? I think what you need to do:

1. I would create a section similar to "New fixes for 2.8", something like "Our changes for 2.8", because this is something we never want to merge back to librdkafka.
2. Add this patch, probabaly referencing only your commit should be fine. If you don't mind adding a note about searching for new cJSON usage is newer kafka versions, it would nice to mention that.
3. Extend the git commands at the end of the document.

This way if we want to update librdkafka to a new version, we know what we have to do to keep the current working state of our fork.

The changes themselves and the idea I think is okay. I am kind of unsure about that parsing thing, and this way we would definitely use the kafka included cJSON more, but let's see what happens.

@antaljanosbenjamin I did as you said, thanks. Wasn't aware that our librdkafka fork comes with such sophisticated upgrade instructions. Definitely useful.

About confluentinc/librdkafka#4159 (comment): There are two ways how cJSON can be misused at the moment:

• a race for the same static initialization handler from librdkafka and aws-c-common, this is fixed by this PR,
• potential non-tread-safety, happens if the same user (e.g. librdkafka) calls certain cJSON functions concurrently (here are some docs about this problem). There is however a chance that librdkafka's usage pattern is safe. Not addressed by this PR. In any case, the crashstack would look different than the one which is fixed here. We could resolve that issue separately if it happens to occur (haven't seen it in CI though).