Directly using non-ascii characters (unicodes included) in *dag_id* breaks
couples of functionalities. See issues:
- Fail to download task log if there are Chinese characters in dag_id
#21127 <https://github.com/apache/airflow/issues/21127>
- Airflow scheduler with statsd enabled crashes when dag_id contains
unexpected characters #18010
<https://github.com/apache/airflow/issues/18010>
- Names for expanded tasks #23020
<https://github.com/apache/airflow/issues/23020>
*Abdul Hadi Shakir*
On Thu, Jan 12, 2023 at 1:19 PM Daniel Standish
<daniel.stand...@astronomer.io.invalid> wrote:
> Hi,
>
> Is it not possible to just have unicode dag_id with no distinct "name"?
> If you explored this route and encountered problems which caused you to
> abandon, can you share what were the problems?
>
> I think having just one ID for a dag is a nice thing, if we can keep it.
>
> On Wed, Jan 11, 2023 at 11:43 PM Abdul Hadi Shakir <shakir.i...@gmail.com>
> wrote:
>
>> Hi team,
>>
>> While discussing the approach for
>> https://github.com/apache/airflow/issues/22073 (adding support for
>> national characters in DAG display name) - two approaches came out. Need
>> votes to finalise on one of the two:
>>
>> 1. [Vote *+1*] Using *name* as the only parameter; and then
>> generating a unique *dag_id* from it using *slugify*. This makes the
>> interface simpler; but it makes *dag_id* unknown from the users.
>> Ongoing PR for this: https://github.com/apache/airflow/pull/28183
>> 2. [Vote -*1*] To use *display_name* along with *dag_id* as DAG
>> params. While this is a simpler solution on the backend - it needs lots of
>> work on the frontend for a consistent experience. Ongoing PR for this:
>> https://github.com/apache/airflow/pull/27145
>>
>> Cheers,
>> *Abdul Hadi Shakir*
>>
>
