🚀 New issue to wemake-services/django-modern-rest by @milssky
📝 Changes in benchmarking (#1505)


While working toward #207, I ran into the need for reliable benchmarking. We currently have four workers benchmarked using ab, which does not properly support HTTP/1.1. In particular, ab turns out to handle the -k flag incorrectly: it sends HTTP/1.0 requests with a Connection: Keep-Alive header, and different servers handle these requests differently. As a result, Uvicorn and Granian are effectively being tested under different conditions.

Furthermore, when multiple workers are used, the benchmark measures more than just the performance of the request-response lifecycle. The load generator creates a limited number of TCP connections, which the operating system distributes among the worker processes. Each keep-alive connection then remains bound to a single worker. This distribution may be uneven and can vary between runs, significantly affecting the resulting RPS.

Therefore, the current results cannot be used to evaluate the impact of individual parts of Django or a future RSGI implementation.

I see two possible approaches:

1. Fix the existing benchmark:
 • replace ab with a load generator that properly supports HTTP/1.1, such as hey;
 • run all servers with a single worker;
 • add Granian running in ASGI mode and soon add Granian in RSGO mode;
 • use the same concurrency level, duration, and other parameters for every server.
2. Keep the existing benchmark unchanged and add a separate benchmark for the request-response lifecycle:
 • use a single worker for Uvicorn, Granian, and Gunicorn;
 • use hey as the primary load generator;
 • run all servers under identical conditions;

Let’s discuss which direction we should take.


#feature #help_wanted #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 `test_custom_union_format` failed in CI (#1533)


Seed for the repro: --randomly-seed=1177358910

FAILED tests/test_unit/test_plugins/test_pydantic/test_pydantic_schema.py::test_custom_union_format[PydanticSerializer] - AssertionError: assert Schema(all_of...ne, defs=None) == Schema(all_of...ne, defs=None)
  
  Omitting 58 identical items, use -vv to show
  Differing attributes:
  ['type']
  
  Drill down into differing attribute type:
    type: [<OpenAPIType.STRING: 'string'>, <OpenAPIType.INTEGER: 'integer'>] != [<OpenAPIType.INTEGER: 'integer'>, <OpenAPIType.STRING: 'string'>]
    At index 0 diff: <OpenAPIType.STRING: 'string'> != <OpenAPIType.INTEGER: 'integer'>
    
    Full diff:
      [
    +     <OpenAPIType.STRING: 'string'>,
          <OpenAPIType.INTEGER: 'integer'>,
    -     <OpenAPIType.STRING: 'string'>,
      ]
FAILED tests/test_unit/test_plugins/test_pydantic/test_pydantic_schema.py::test_custom_union_format[PydanticFastSerializer] - AssertionError: assert Schema(all_of...ne, defs=None) == Schema(all_of...ne, defs=None)
  
  Omitting 58 identical items, use -vv to show
  Differing attributes:
  ['type']
  
  Drill down into differing attribute type:
    type: [<OpenAPIType.STRING: 'string'>, <OpenAPIType.INTEGER: 'integer'>] != [<OpenAPIType.INTEGER: 'integer'>, <OpenAPIType.STRING: 'string'>]
    At index 0 diff: <OpenAPIType.STRING: 'string'> != <OpenAPIType.INTEGER: 'integer'>
    
    Full diff:
      [
    +     <OpenAPIType.STRING: 'string'>,
          <OpenAPIType.INTEGER: 'integer'>,
    -     <OpenAPIType.STRING: 'string'>,
      ]

https://github.com/wemake-services/django-modern-rest/actions/runs/34912494319/job/104202853421?pr=1510


#bug #help_wanted #ci #opensource_september #django_modern_rest
sent via relator

🚀 New issue to faststream-community/zMQTT by @borisalekseev
📝 Mark flaky Artemis test xfail (#104)


Artemis test flaks here: https://github.com/faststream-community/zMQTT/actions/runs/35749462095/job/106819499609

Mark it xfail(strict=False)


#good_first_issue #opensource_september #faststream #zmqtt
sent via relator

🚀 New issue to ag2ai/faststream by @IvanKirpichnikov
📝 Feature: Implementation of the `AsyncContextManager` interface for `Application` (#3228)


Is your feature request related to a problem? Please describe.
Instead of

await app.start()
try:
    ...
finally:
    await app.stop()

I want to do

async with app:
    ...

Describe the solution you'd like
Implementation of the AsyncContextManager interface for Application

This should work for Application subclassses, i.e., for FastStream and AsgiFastStream.

TestApp already has this capability. It just needs to be adjusted to use __aenter__ and __aexit__.

Feature code example

async with app:
    ...

#enhancement #good_first_issue #faststream #ag2ai
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 `CookieJWT[A]syncAuth` and `HeaderJWT[A]syncAuth` have the same security schema name (#1587)


This makes it impossible to use them together in a single endpoint / contoller together by default. Only a single jwt security schema / requirement will be generated.

Which is not correct. We need to change the CookieJWT[A]syncAuth one to be jwt_cookie


#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Flaky `test_empty_validate_responses` (#1588)

 ________________________ test_empty_validate_responses _________________________
    
    settings = <pytest_django.fixtures.Settings object at 0x7f00e6dbba90>
    
        def test_empty_validate_responses(settings: LazySettings) -> None:
            """Ensure that `EMPTY` on `validate_responses` raises."""
            settings.DMR_SETTINGS = {
                Settings.validate_responses: EMPTY,
            }
        
    >       with pytest.raises(EndpointMetadataError, match='validate_responses'):
    E       AssertionError: Regex pattern did not match.
    E         Expected regex: 'validate_responses'
    E         Actual message: 'Settings validation failed'

Link: https://github.com/wemake-services/django-modern-rest/actions/runs/36040317321/job/107770717079

The fix is very welcome!


#bug #good_first_issue #help_wanted #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 `_validate_throttling` check is a bad design :( (#1600)


This code

django-modern-rest/dmr/validation/endpoint_metadata.py

Lines 934 to 971 in 6649d05

knows a lot about specific backends for throttling. But, why do we do this in metadata validation? Why don't we create .validate method in throttling (and auth just in case) objects instead?

Like we do for parser and renderer objects:

django-modern-rest/dmr/parsers.py

Lines 47 to 58 in 6649d05

This way we can validate objects directly where they know how to self-validate.


#feature #good_first_issue #help_wanted #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/wemake-python-styleguide by @sobolevn
📝 Incorrect Jones complexity for formatted strings (#3820)


These two lines:

• tuple(f'/{pref.strip("/")}/' for pref in (prefix, *prefixes))
• tuple(f'/{pref.strip("/")}' for pref in (prefix, *prefixes)) (notice the missing / at the end)

have different Jones complexity.
They must not. It should be counted as:

• 1 per every {}
• As regular for all python expressions inside {}
• All string parts of fstring are counted as total of 1

#bug #help_wanted #levelstarter #good_first_issue #wemake_python_styleguide #wps
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 `Settings.throttling_allow_unsafe_cache` is a bad design (#1611)


After #1600 we moved the throttling validation to throttling classes.

So, there's no need for a global setting now. It must be removed and we must add allow_unsafe_cache parameter to _DjangoCache instead.


#feature #good_first_issue #help_wanted #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @vyhuholl
📝 Seeded OpenAPI examples of `datetime` and `time` change with the current time (#1632)


What's wrong?

Found while working on #1629. With DMR_SETTINGS = {'openapi_examples_seed': 1} and the same PYTHONHASHSEED, examples of datetime and time fields are different on every run:

class _Event(msgspec.Struct):
    created_at: dt.datetime
    day: dt.date
    at: dt.time
    duration: dt.timedelta


class _EventController(Controller[MsgspecSerializer]):
    def get(self) -> _Event:
        raise NotImplementedError

Two runs 3 seconds apart, both with PYTHONHASHSEED=0:

02:18:43  {"created_at": "2000-10-08T03:39:12.378838", "day": "2025-09-16", "at": "18:36:00.366279", "duration": "P0D"}
02:18:46  {"created_at": "2000-10-08T03:39:16.378838", "day": "2025-09-16", "at": "18:36:03.421377", "duration": "P0D"}

polyfactory generates these with Faker, and Faker's defaults end at the current time: datetime uses date_time_between, which ends at "now", and time uses time_object, which picks a time between 1970 and now. The seed fixes the random part, but the range moves with the clock, so the value moves too. date uses date_this_decade, which ends at today, so it changes once a day.

So a schema with such fields is never the same on two runs, even though the seed_example_factory docstring says that seeding per build "keeps a schema reproducible on its own".

How it should be?

The same openapi_examples_seed should give the same examples at any time. _ExampleFactory in dmr/openapi/mappers/example.py can override get_provider_map() and give datetime, date and time fixed bounds instead of "now".

timedelta could get a range there too: its examples are always P0D now, because time_delta() without end_datetime starts and ends at "now".

Used versions

django-modern-rest 0.15.0, polyfactory 3.3.0, faker 40.39.0

Reproduced on c35128a.

OS information

macOS 27.0


#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/wemake-python-styleguide by @sobolevn
📝 `WPS235`: ignore imports from `typing` (#3824)


I can't limit the number of types I import from typing, I can't refactor types to use typing. prefix and import import typing

We need to just ignore this module. And typing_extensions as well.


#bug #help_wanted #levelstarter #good_first_issue #wemake_python_styleguide #wps
sent via relator