🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Fix unused `security` field in `EndpointMetadata` and `_BasePayload` (#1499)


We don't use these two things:

1. security field documentation here:

 django-modern-rest/dmr/metadata.py

 Lines 429 to 430 in f822e35

2. django-modern-rest/dmr/validation/payload.py

 Line 44 in f822e35

However, I don't think that this is right. Users must have an option to configure this directly.
Let's create this rule:

• Any user provided security objects must be saved to the metadata
• It must be merged with explicit auth= providers

It might be useful when people define some external security mechanims, for example that work on HTTP proxy level, or in other microservices.

New snapshot test is required for this change.


#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
📝 Fix `operation_id` default generation rules (#1500)


Currently it produces: getAuthedandcookiescontrollerApiCookies for _AuthedAndCookiesController, see

django-modern-rest/tests/test_unit/test_plugins/test_msgspec/test_msgspec_snapshots.py

Lines 61 to 81 in f822e35

It must produce: getAuthedAndCookiesControllerApiCookies
Please, update all existing snapshots.


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

🚀 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