Behavior change in airflow db clean after upgrading from Airflow 3.0.6 to 3.1.x (Read-only filesystem error)

[kang-seongbeom]

After upgrading Airflow from 3.0.6 to 3.1.0, I am seeing a change in behavior with the airflow db clean command.
I am running Airflow on Kubernetes. To clean the database, I use a Kubernetes CronJob that creates a separate Airflow pod and executes airflow db clean inside that pod. This setup worked without any issues up to Airflow 3.0.6.
However, when using Airflow 3.1.0 or later, the airflow db clean command fails with the following error:

OSError: [Errno 30] Read-only file system: '/opt/airflow/logs'

Because of this error, the Cronjob does not complete successfully.
My questions are:

1. Has the behavior of airflow db clean changed in Airflow 3.1.x compared to 3.0.6?
2. I could not find any related changes mentioned in the release notes—was this change intentional?
3. Why does airflow db clean, which is a database-related command, attempt to access the log directory and fail due to a read-only filesystem?

Any clarification or guidance would be greatly appreciated.

[potiuk]

Could you please provide more details and stack trace of the failing case? Whether it's intentional or bug can be likely answere after seeing where it occurs.