[Bugfix] Fix LOGITPROC_SOURCE_ENTRYPOINT test to use spawn-compatible dist-info registration for XPU/ROCm

[dzhengAP]

Follow-up to #41423, also discussed in #41895.

Problem

test_custom_logitsprocs[LOGITPROC_SOURCE_ENTRYPOINT] and
test_rejects_custom_logitsprocs[LOGITPROC_SOURCE_ENTRYPOINT] relied on
fork-based monkey-patching of importlib.metadata.entry_points to inject a
fake logitproc entrypoint.

That works with VLLM_WORKER_MULTIPROC_METHOD=fork, but it is not compatible
with XPU/ROCm platforms where the tests need to run with spawn-based
multiprocessing. With spawn, the monkey-patched entrypoint state is not
inherited by worker subprocesses, so the fake custom logits processor entrypoint
cannot be discovered.

Fix

Replace the spawn path’s in-memory monkey-patch with a real temporary
.dist-info package written to disk and exposed through PYTHONPATH.

Since importlib.metadata discovers entrypoints from installed package metadata
on disk, spawned subprocesses can discover the fake logitproc entrypoint without
requiring fork.

This PR adds/updates the shared fake-entrypoint setup in
tests/v1/logits_processors/utils.py to:

1. Create a temporary .dist-info directory with METADATA and
   entry_points.txt.
2. Add the temporary package directory to PYTHONPATH so spawned subprocesses
   can discover the entrypoint.
3. Prepend the same directory to sys.path so the current driver process can
   discover the entrypoint as well.
4. Use spawn-compatible registration when spawn multiprocessing is required.
5. Keep the existing monkey-patched importlib.metadata.entry_points behavior
   for fork-based test execution.

The follow-up commits also apply this setup consistently across the custom
offline and online logits processor tests.

This makes the custom logits processor entrypoint tests compatible with
spawn-based multiprocessing and fixes the XPU/ROCm CI failures.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[gemini-code-assist]

Code Review

This pull request refactors the custom logits processor tests to support spawned subprocesses by replacing manual monkey-patching of importlib.metadata.entry_points with a disk-based dist-info registration. A new utility function, register_fake_entrypoint, creates a temporary package and updates PYTHONPATH. Feedback indicates that sys.path should also be updated for the current process to ensure the driver process can successfully discover the entry point.

[zhenwei-intel]

tests/v1/logits_processors/test_custom_online.py
Could you please also handle this test?

[AndreasKaratzas]

CI is blocked, so I could not wait for the author. Opened a second PR here with their commits as well to honor their contributions:

• [ROCm][CI] Fix custom logits entrypoints for ROCm/XPU spawn #42115

UPDATE: Author is back and people can officially call me impatient.

[dzhengAP]

Good sign is the fix focused in this PR is passed in Intel CI. The only fail is LoRA, which has been already discussed here. It can be waived due to current XPU limitation support on LoRA. #41895 (comment)

Deeper insight: So this Qwen3.5 dense model path uses a GDN/Mamba-style layer where LoRA projections are not supported on XPU. The correct fix is to skip this test on XPU, not try to make it pass. @zhenwei-intel @jikunshang

[jikunshang]

Good sign is the fix focused in this PR is passed in Intel CI. The only fail is LoRA, which has been already discussed here. It can be waived due to current XPU limitation support on LoRA. #41895 (comment)

Deeper insight: So this Qwen3.5 dense model path uses a GDN/Mamba-style layer where LoRA projections are not supported on XPU. The correct fix is to skip this test on XPU, not try to make it pass. @zhenwei-intel @jikunshang

we disable some lora case on main, please rebase and check whether it pass.

[AndreasKaratzas]

@dzhengAP could you rebase? I think AMD docker build is having some very temporary issues.

[jikunshang]

rebased. let's see what CI say.

[dzhengAP]

Intel CI all passed, but AMD CI still running after 3hours, do we have any experience or estimation of the typical AMD CI ruining time?@AndreasKaratzas and @jikunshang

[AndreasKaratzas]

@dzhengAP Yep, but AMD CI is like that(and it is not blocking), I was only interested in the blocking test group, and it is passing now. I am going to ping people in slack.

[tjtanaa]

LGTM