🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Support `Path` with `*args` (#754)


Right now Path component only supports parsing from request.kwargs. Which is like 99% of cases.
However, parsing from request.args is not supported:

django-modern-rest/dmr/components.py

Lines 655 to 662 in b3f9c08

What should we do instead?

1. When request.args is provided we should require models like:

>>> import pydantic
>>> class UserId(pydantic.BaseModel):
...     user_id: int

>>> PathModel = pydantic.RootModel[tuple[tuple[int, ...], UserId]]

>>> PathModel.model_validate((('1', '2', '3'), {'user_id': 10}))
RootModel[tuple[tuple[int, ...], UserId]](root=((1, 2, 3), UserId(user_id=10)))

1. We would return tuple[Args, Kwargs] from this component if request.args is set
2. Test this with unnamed re_path urls https://docs.djangoproject.com/en/6.0/topics/http/urls/#using-unnamed-regular-expression-groups
3. Test this in tests/test_unit/test_components/test_path.py
4. Document this feature in docs/pages/components/path.rst
5. Provide an example in docs/examples/components/path_args.py and include it to path.rst
6. Provide a changelog entry
7. Remove _UNNAMED_PATH_PARAMS_MSG and all translations of this string, recompile all translations with make translations

Contributions are welcome! This is an intermediate level task :)


#enhancement #good_first_issue #help_wanted #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Provide our own `settings` fixture (#760)


When using settings fixture from pytest-django we frequently change them.
However, we have dmr_clean_settings fixture, which should be use when we touch our own settings.

So, let's add a new fixture to dmr_pytest.py which will return unchanged settings: LazySettings, but will also use dmr_clean_settings.

Also, remove all dmr_clean_settings from our own tests, where settings is used.


#enhancement #good_first_issue #help_wanted #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Provide `dmr.cookies.set_cookies` helper function (#773)


Currently we have two places where we duplicate this code:

django-modern-rest/dmr/streaming/controller.py

Lines 172 to 178 in a6bc356

and

django-modern-rest/dmr/response.py

Lines 256 to 259 in a6bc356

So, it can probably be useful to others as well.
Let's move this to cookies.py as a public helper function.

Also, document it in public-api.rst

This is a very easy task for new contributors.


#enhancement #good_first_issue #help_wanted #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Test and declare officail `NamedTuple` support (#774)


Here's the code:

>>> from typing import NamedTuple
>>> class A(NamedTuple):
...     x: int
...     y: int
...     
>>> import pydantic
>>> pydantic.TypeAdapter(A).validate_python({'x': 1, 'y': 2})
A(x=1, y=2)
>>> pydantic.TypeAdapter(A).validate_python({'x': 1, 'y': 'a'})
Traceback (most recent call last):
  File "<python-input-11>", line 1, in <module>
    pydantic.TypeAdapter(A).validate_python({'x': 1, 'y': 'a'})
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
  File "/Users/sobolev/Desktop/django-modern-rest/.venv/lib/python3.13/site-packages/pydantic/type_adapter.py", line 441, in validate_python
    return self.validator.validate_python(
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        object,
        ^^^^^^^
    ...<6 lines>...
        by_name=by_name,
        ^^^^^^^^^^^^^^^^
    )
    ^
pydantic_core._pydantic_core.ValidationError: 1 validation error for call[A]
y
  Input should be a valid integer, unable to parse string as an integer [type=int_parsing, input_value='a', input_type=str]
    For further information visit https://errors.pydantic.dev/2.12/v/int_parsing

As we can see, NamedTuple models work well with pydantic. So, here's what we need to do:

1. Add a test case to test_plugins/test_pydantic that it works with NamedTuple
2. Add a doc example here https://django-modern-rest.readthedocs.io/en/latest/pages/getting-started.html#showcase
3. Add a changelog entry, that it is now officially supported

We welcome new contributors :)


#enhancement #good_first_issue #help_wanted #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Add docs and example about `django-health-check` integration (#831)


One can use https://github.com/codingjoe/django-health-check for health checks.
No special integration from our side is required.

This information can be added here: https://github.com/wemake-services/django-modern-rest/blob/master/docs/pages/integrations.rst


#documentation #enhancement #good_first_issue #help_wanted #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Support `orjson` as a possible backend for `JsonParser` / `JsonRenderer` (#857)


Currently we always use json as a module in JsonParser and JsonRenderer:

django-modern-rest/dmr/parsers.py

Lines 132 to 134 in 69822ff

But, we can make this module customizable. We can pass orjson module there, since it also has a similar API.

Something like:

class JsonParser(Parser):
    __slots__ = ('_json_module', ...)
    def __init__(self, json_module: _JsonModule = json, ...) -> None:
       self._json_module = json_module

And later self._json_module.loads(...)

This would need multiple test cases: install orjson as unit-test dependency and add unit tests for this new renderer / parser.
And we can document that with an example in the integrations.rst docs.


#enhancement #good_first_issue #help_wanted #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Add a Django command to export OpenAPI schemas (#858)


It migth be useful to people who want to share the schema. Or automate something with it.

I propose to add a django command: dmr_export_schema.
Args:

• Where to find schema, I think we should reuse import_string logic from Django. Required
• All json formatting ones: sort_keys and indent
• Format: json or yaml, check that yaml is installed. Default is json

We should print it to the stdout always. Usages:

# regular:
python manage.py dmr_export_schema server.urls:schema

# pretty:
python manage.py dmr_export_schema server.urls:schema --format json --indent=2 --sort-keys

This would need tests, we can test it as a subprocess, it is a django command after all.
And docs.


#enhancement #good_first_issue #help_wanted #django_modern_rest
sent via relator

🚀 New issue to ag2ai/faststream by @ce1ebrimbor
📝 Feature: Support broker-level ack_policy default with per-subscriber override (#2826)


Problem

Currently ack_policy can only be set per-subscriber:

@broker.subscriber("orders.topic", ack_policy=AckPolicy.NACK_ON_ERROR)
async def handle_order(msg: OrderMessage) -> None:
    ...

There is no way to set a default ack_policy at the broker (or router) level. In practice, most services want the same policy across all subscribers — typically NACK_ON_ERROR for at-least-once delivery with DLQ. This forces every @broker.subscriber() call to repeat the same ack_policy= argument, which is error-prone: forgetting it on a single subscriber silently falls back to ACK_FIRST (at-most-once), which can cause silent message loss.

Proposed solution

Add an ack_policy parameter to KafkaBroker (and equivalently to RabbitBroker, NatsBroker, etc.) that sets the default for all subscribers registered on that broker. Individual subscribers can still override it.

broker = KafkaBroker("localhost:9092", ack_policy=AckPolicy.NACK_ON_ERROR)

# Inherits NACK_ON_ERROR from broker
@broker.subscriber("orders.topic")
async def handle_order(msg: OrderMessage) -> None:
    ...

# Overrides to ACK for this specific subscriber
@broker.subscriber("notifications.topic", ack_policy=AckPolicy.ACK)
async def handle_notification(msg: NotificationMessage) -> None:
    ...

The resolution order would be: subscriber-level > broker-level > built-in default (ACK_FIRST).

Why this matters
• Safety: ACK_FIRST as a silent default is dangerous for services that use DLQ or need at-least-once delivery. A broker-level default lets teams enforce their delivery guarantee in one place.
• DRY: Services with 10+ subscribers shouldn't need to repeat ack_policy=AckPolicy.NACK_ON_ERROR on every one.
• Consistency with other broker-level settings: decoder, middlewares, security, and logger are all broker-level defaults that subscribers inherit. ack_policy is the notable exception.

#enhancement #good_first_issue #faststream #ag2ai
sent via relator

🚀 New issue to ag2ai/faststream by @dzeveloper
📝 Feature: Consumer-Only Mode for KafkaBroker (#2879)


When deploying a subscriber-only service, it's common to provision Kafka credentials scoped strictly to READ + DESCRIBE ACLs on specific topics. Today, KafkaBroker always starts a producer during broker.start(), regardless of whether any @broker.publisher is registered. This causes the producer to attempt a connection using consumer-only credentials, which fails or raises errors at the broker/ACL level.

Proposal:

# Option A: broker-level flag
broker = KafkaBroker("localhost:9092", consumer_only=True)

# Option B: skip producer if no publishers are registered (automatic)
# No API change needed — broker inspects registered publishers at start()

#enhancement #good_first_issue #confluent #aiokafka #faststream #ag2ai
sent via relator

🚀 New issue to ag2ai/faststream by @DeoLeung
📝 Feature: relax typer version (#2969)


if no incompatibility, it will be great to relax the cap of typer, easy for projects using faststream cli to upgrade typer


#enhancement #good_first_issue #faststream #ag2ai
sent via relator

🚀 New issue to ag2ai/faststream by @IvanKirpichnikov
📝 Feature: Add `RedisBatchStreamMessage` annotated alias (#3004)


Add to faststream/redis/annotations.py the alias for RedisBatchStreamMessage is similar to the aliases for RedisMessage, RedisChannelMessage, etc.


#enhancement #good_first_issue #redis #faststream #ag2ai
sent via relator

🚀 New issue to ag2ai/faststream by @Lancetnik
📝 Feature: `StreamSub(declare=False)` to opt out of Redis Stream creation (#3013)


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

FastStream creates the Redis Stream for you whenever a subscriber uses a consumer group — mkstream=True is hardcoded and there is no way to turn it off:

faststream/faststream/redis/subscriber/usecases/stream_subscriber.py

Lines 133 to 138 in 2e36197

That is a fine default, but it means a typo in a stream name silently provisions a new empty stream instead of failing, and a service that is only supposed to consume a stream provisioned elsewhere has no way to say so. Every other broker in FastStream already has this opt-out — RabbitQueue(declare=False), RabbitExchange(declare=False), JStream(declare=False), KvWatch(declare=False), ObjWatch(declare=False). Redis is the only one missing it. The same knob is being added to Kafka in #1827.

Describe the solution you'd like

A declare: bool = True argument on StreamSub, passed through as mkstream=not declare. Default behaviour does not change.

Feature code example

from faststream import FastStream
from faststream.redis import RedisBroker, StreamSub

broker = RedisBroker()
app = FastStream(broker)


# unchanged default — stream is created if missing
@broker.subscriber(stream=StreamSub("orders", group="g", consumer="c"))
async def owned(msg: str) -> None: ...


# provisioned elsewhere — fail fast instead of creating an empty stream
@broker.subscriber(
    stream=StreamSub("external-events", group="g", consumer="c", declare=False)
)
async def consumed(msg: str) -> None: ...

Semantics

Redis only offers the "check, do not create" form, so declare=False fails when the stream is absent — the same as RabbitMQ's declare=False (AMQP passive=True), and unlike NATS' variant which just skips creation. Verified against redis:alpine:

mkstream=False -> ResponseError: The XGROUP subcommand requires the key to exist.
                  Note that for CREATE you may want to use the MKSTREAM option to
                  create an empty stream automatically.
exists after mkstream=False: 0
mkstream=True  -> exists after: 1

The existing except ResponseError only swallows "already exists", so this error propagates as-is today — which is the wanted behaviour. Wrapping it in a FastStream error with a message pointing at declare=False would be a nice touch, not a requirement.

Implementation notes

1. Add declare: bool = True to StreamSub.__init__ and to __slots__ —

 faststream/faststream/redis/schemas/stream_sub.py

 Lines 44 to 69 in 2e36197

 — plus an Args: entry in the class docstring.
2. Pass mkstream=not stream.declare at the xgroup_create call linked above.
3. declare only has an effect on the consumer-group path — that xgroup_create runs only when group and consumer are both set. Without a group the subscriber uses XREAD, which never creates anything. StreamSub already emits RuntimeWarning for argument combinations that have no effect (no_ack with a group, polling_interval with last_id != ">"); declare=False without a group deserves the same treatment.
4. Tests go in tests/brokers/redis/ — one real-broker case asserting the stream is not created and the error surfaces, one asserting the default still creates it.

Out of scope: publishing. XADD always creates the stream and Redis exposes no flag to prevent it, so there is no publisher-side equivalent.

Additional context

Prior art to copy the naming and docstring style from: RabbitQueue.declare and JStream.declare.


#enhancement #good_first_issue #redis #faststream #ag2ai
sent via relator

🚀 New issue to faststream-community/zMQTT by @borisalekseev
📝 Add Last Will support to the public MQTTClient API (#45)


Problem

zmqtt already implements MQTT Last Will at the packet/codec level, but it
cannot be configured through the public high-level client API.

Currently:

• Will and WillProperties are only available through private
 zmqtt._internal modules;
• MQTTClient and create_client() do not accept a will= argument;
• MQTTClient._connect() builds every CONNECT packet without a Will.

As a result, users and frameworks built on the public zmqtt.MQTTClient API,
including FastStream, cannot configure an MQTT Last Will without depending on
private implementation details.

Proposed API

from zmqtt import MQTTClient, QoS, Will, WillProperties

will = Will(
    topic="devices/device-42/status",
    payload=b"offline",
    qos=QoS.AT_LEAST_ONCE,
    retain=True,
    properties=WillProperties(
        will_delay_interval=10,
        content_type="text/plain",
    ),
)

client = MQTTClient(
    "broker.example.com",
    version="5.0",
    will=will,
)

For MQTT 3.1.1, the same Will type should be usable without
WillProperties.

Scope
• Export Will and WillProperties from the top-level zmqtt package.
• Add will: Will | None = None to MQTTClient.
• Add the same argument to create_client() and all of its typed overloads.
• Store the configured Will and pass it to every Connect packet created by
 the client.
• Preserve the same Will configuration when the client reconnects after an
 established connection is lost.
• Reject MQTT 5.0 Will properties on MQTT 3.1.1 with a clear error consistent
 with other version-specific options.
• Keep the current behavior unchanged when will=None.

Tests

The tests should exercise the public client path rather than only the existing
packet codec:

• MQTT 3.1.1: construct MQTTClient(..., will=...), decode the emitted
 CONNECT, and verify the Will topic, payload, QoS, and retain flag.
• MQTT 5.0: verify the same fields together with WillProperties.
• Simulate will receiving of second client when the first reconnected unexpectedly

Tests should test public behaviour with real broker instead internals testing and avoid monkey patching.


#enhancement #good_first_issue #faststream #zmqtt
sent via relator

🚀 New issue to ag2ai/faststream by @Lancetnik
📝 Feature: use aio_pika.Pool to connect RMQ (#975)


For now, FastStream uses a regular RobustConnection and RobustChannel to connect RabbitMQ, but we should support aio-pika connection Pool feature in this case

https://aio-pika.readthedocs.io/en/latest/quick-start.html#connection-pooling

Probably, regular behavior should be the Pool with size 1


#enhancement #good_first_issue #rabbitmq #100 #faststream #ag2ai
sent via relator

🚀 New issue to ag2ai/faststream by @Lancetnik
📝 feature: document RPC responses in AsyncAPI (#1586)



#enhancement #good_first_issue #core #asyncapi #faststream #ag2ai
sent via relator

🚀 New issue to ag2ai/faststream by @sobolevn
📝 Consider using `syrupy` for tests (#2978)


Link: https://pypi.org/project/syrupy/

Example usage:

• https://github.com/wemake-services/django-modern-rest/blob/master/tests/test_unit/test_plugins/test_msgspec/test_msgspec_snapshots.py
• https://github.com/wemake-services/django-modern-rest/blob/master/tests/test_unit/test_plugins/test_msgspec/__snapshots__/test_msgspec_snapshots.ambr

#enhancement #good_first_issue #dependencies #faststream #ag2ai
sent via relator

🚀 New issue to ag2ai/faststream by @kumaranvpl
📝 Ability to configure topic params in confluent create_topics (#1827)


Current state: every topic FastStream creates is created with num_partitions=1, replication_factor=1, hardcoded:

faststream/faststream/confluent/helpers/admin.py

Lines 52 to 55 in 2e36197

The only knob users have is the broker-wide allow_auto_create_topics flag — all topics of a broker are created, or none of them are. There is no way to configure a single topic, nor to opt a single topic out of creation.

Request: introduce a Topic schema object accepted by subscriber() / publisher() alongside plain strings, carrying per-topic settings:

from faststream.confluent import KafkaBroker, Topic

broker = KafkaBroker()

@broker.subscriber(
    Topic("topic-name", num_partitions=3),
    Topic("topic-name2", num_partitions=1, replication_factor=2),
    Topic("externally-managed", declare=False),
    "topic-without-settings",
)
async def handler(msg: str) -> None: ...

Scope

1.

 num_partitions / replication_factor per topic — the original ask, from https://github.com/airtai/faststream/discussions/1821. Today both are pinned to 1, which makes FastStream-created topics unusable in any real deployment.

2.

 declare: bool = True — opt a single topic out of creation while auto-creation stays the default for everything else. This subsumes #2679: the global default is not changing, because a broker-wide switch is the wrong granularity — a service typically owns some of its topics and consumes others that are provisioned by a different team or by IaC.

Proposed semantics of declare=False: skip the create_topics call for that topic and nothing else — do not probe the cluster for existence, do not fail if the topic is missing. This matches what allow_auto_create_topics=False does today (a warning, then let the consumer proceed) and matches NATS' JStream(declare=False). Note this deliberately differs from RabbitMQ's RabbitQueue(declare=False), which maps to AMQP passive=True and does raise when the queue is absent — Kafka has no cheap equivalent of a passive declare.

Interaction with the broker-level flag: allow_auto_create_topics=False on the broker keeps winning over everything — it stays the "create nothing at all" switch. declare only narrows creation further when the broker-level flag is on.

Consistency across brokers: declare is the established name for this in FastStream — RabbitQueue(declare=...), JStream(declare=...), KvWatch(declare=...), ObjWatch(declare=...). Topic should use the same name rather than inventing a Kafka-specific one.

AioKafka is out of scope. FastStream never creates topics for faststream.kafka — there is no AdminClient.create_topics call on that path, and aiokafka (0.13.0) does not support an allow_auto_create_topics consumer option at all:

$ grep -rn "auto_create\|auto\.create" .venv/lib/python3.11/site-packages/aiokafka/
$ grep -rn "auto_create" faststream/kafka/

Both return nothing. Topic creation on that path is entirely the Kafka server's auto.create.topics.enable, which FastStream cannot influence. Topic may still be accepted there later for symmetry, but declare would be a no-op, so it should not block this issue.

Implementation notes

• create_subscriber() / create_publisher() signatures must accept str | Topic — *topics: str is what currently trips mypy on the branch in progress.
• Normalise str → Topic(name) at registration time, as RabbitMQ does with str → RabbitQueue.
• AsyncConfluentConsumer.topics_to_create should filter on declare —

 faststream/faststream/confluent/helpers/client.py

 Lines 292 to 294 in 2e36197

• Topic needs __hash__ / __eq__ consistent with each other, since topics end up as dict keys (see #2796 for the RabbitMQ precedent).

Related: #2679 (closed in favour of this), #1486, #1658, #2451.


#enhancement #good_first_issue #confluent #kafka #faststream #ag2ai
sent via relator

🚀 New issue to ag2ai/faststream by @davorrunje
📝 Docs: dealing with different schema registries (#1297)


It would be good to add documentation with examples how to deal with different schema registries. Again there are many registries and coupling router with a particular registry isn't a good idea, unless there will be a some Abstract class first, so later community can add implementation


#documentation #enhancement #good_first_issue #confluent #faststream #ag2ai
sent via relator

🚀 New issue to ag2ai/faststream by @sobolevn
📝 Consider using `syrupy` for tests (#2978)


Link: https://pypi.org/project/syrupy/

Example usage:

• https://github.com/wemake-services/django-modern-rest/blob/master/tests/test_unit/test_plugins/test_msgspec/test_msgspec_snapshots.py
• https://github.com/wemake-services/django-modern-rest/blob/master/tests/test_unit/test_plugins/test_msgspec/__snapshots__/test_msgspec_snapshots.ambr

#enhancement #good_first_issue #dependencies #faststream #ag2ai
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