Add workaround for shared field_names in pydantic model class

[maxdebayser]

FIX #13880
FIX #13881

In the code below, field_names end up being shared by different classes when they are related by inheritance, in this case: ChatCompletionLogProbsContent(ChatCompletionLogProb). Since the cache is built only once, if the first model that is validated comes from the super class, the cache will be wrong for the derived class from then on. Redefining the field_names seems to prevent this from happening. Another way is to break up the inheritance and add all fields from ChatCompletionLogProb in ChatCompletionLogProbsContent.

class OpenAIBaseModel(BaseModel):
    # OpenAI API does allow extra fields
    model_config = ConfigDict(extra="allow")

    # Cache class field names
    field_names: ClassVar[Optional[Set[str]]] = None

    @model_validator(mode="wrap")
    @classmethod
    def __log_extra_fields__(cls, data, handler):
        result = handler(data)
        if not isinstance(data, dict):
            return result
        field_names = cls.field_names
        if field_names is None:
            # Get all class field names and their potential aliases
            field_names = set()
            for field_name, field in cls.model_fields.items():
                field_names.add(field_name)
                if alias := getattr(field, 'alias', None):
                    field_names.add(alias)
            cls.field_names = field_names

        # Compare against both field names and aliases
        if any(k not in field_names for k in data):
            logger.warning(
                "The following fields were present in the request "
                "but ignored: %s",
                data.keys() - field_names)
        return result

cc: @njhill

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

🚀

[vrdn-23]

@maxdebayser Is this PR still being merged in? I'm seeing the same warning in the latest version as well
cc @DarkLight1337

[maxdebayser]

@vrdn-23 , no it wasn't.

[DarkLight1337]

The tests pass now so it should be fine to merge, sorry for forgetting about this!