🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 It is possible to produce an empty `description` for `ResponseBody` (#1495)
django-modern-rest/dmr/openapi/generators/component_parsers.py
Lines 193 to 199 in f822e35
It misses
#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator
📝 It is possible to produce an empty `description` for `ResponseBody` (#1495)
django-modern-rest/dmr/openapi/generators/component_parsers.py
Lines 193 to 199 in f822e35
It misses
or None part. Because we only skip None values from dumping.#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
📝 Test that nested URL patterns produce correct parameters (#1496)
We need to test a case like:
It might contain a bug: we should get two path parameters, not one.
#good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator
📝 Test that nested URL patterns produce correct parameters (#1496)
We need to test a case like:
Router('tenants/<int:tenant_id>/', [path('users/<int:pk>/', MyController.as_view())])It might contain a bug: we should get two path parameters, not one.
#good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator
🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Test explicit `OpenAPIConfig.security` definition with `auth=None` per-endpoint (#1497)
Looks like we have a potential bug in how we define
Here we always return
django-modern-rest/dmr/openapi/generators/security_scheme.py
Lines 24 to 37 in f822e35
But, if per-document
Which is wrong.
This would require a test and a fix. Maybe we should look at current config's
#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator
📝 Test explicit `OpenAPIConfig.security` definition with `auth=None` per-endpoint (#1497)
Looks like we have a potential bug in how we define
security in OpenAPI.Here we always return
None:django-modern-rest/dmr/openapi/generators/security_scheme.py
Lines 24 to 37 in f822e35
But, if per-document
security is set, we need to return [] as the value. Otherwise, None won't be dumped by our None-ignoring dump_schema rules. And security rules per this endpoint will be inherited from the document.Which is wrong.
This would require a test and a fix. Maybe we should look at current config's
security to define the return type?#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 unused `security` field in `EndpointMetadata` and `_BasePayload` (#1499)
We don't use these two things:
1.
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
• It must be merged with explicit
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
📝 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= providersIt 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:
django-modern-rest/tests/test_unit/test_plugins/test_msgspec/test_msgspec_snapshots.py
Lines 61 to 81 in f822e35
It must produce:
Please, update all existing snapshots.
#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator
📝 Fix `operation_id` default generation rules (#1500)
Currently it produces:
getAuthedandcookiescontrollerApiCookies for _AuthedAndCookiesController, seedjango-modern-rest/tests/test_unit/test_plugins/test_msgspec/test_msgspec_snapshots.py
Lines 61 to 81 in f822e35
It must produce:
getAuthedAndCookiesControllerApiCookiesPlease, 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
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
• 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
• run all servers under identical conditions;
Let’s discuss which direction we should take.
#feature #help_wanted #django_modern_rest
sent via relator
📝 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:
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
📝 `test_custom_union_format` failed in CI (#1533)
Seed for the repro:
--randomly-seed=1177358910FAILED 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
Forwarded from Сергей Озеранский
Помните про https://github.com/ozeranskii/httptap?
Я писал о нем давно еще - > тут.
Наклепал много issue, для тех кто хочет вкатиться в OSS или попрактиковаться себя и свою LLM - welcome. Только, пожалуйста, без нейрослопа и не будьте meat-proxy. Не хочу тратить время на фиксы фиксов. Ибо вот даже простой фикс, я исправил (смотри историю коммитов в PR), так как почитал документацию, а автор видимо нет.
Я писал о нем давно еще - > тут.
Наклепал много issue, для тех кто хочет вкатиться в OSS или попрактиковаться себя и свою LLM - welcome. Только, пожалуйста, без нейрослопа и не будьте meat-proxy. Не хочу тратить время на фиксы фиксов. Ибо вот даже простой фикс, я исправил (смотри историю коммитов в PR), так как почитал документацию, а автор видимо нет.
GitHub
GitHub - ozeranskii/httptap: Rich-powered CLI that breaks each HTTP request into DNS, connect, TLS, wait, and transfer phases with…
Rich-powered CLI that breaks each HTTP request into DNS, connect, TLS, wait, and transfer phases with waterfall timelines, compact summaries, or metrics-only output. - ozeranskii/httptap
🔥5
🚀 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
📝 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
I want to do
Describe the solution you'd like
Implementation of the
This should work for
Feature code example
#enhancement #good_first_issue #faststream #ag2ai
sent via relator
📝 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 ApplicationThis 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