o-nikolas commented on PR #39046: URL: https://github.com/apache/airflow/pull/39046#issuecomment-2065380959
> Feels like a teeny tiny step toward AIP-66, but makes it inconsistent with the rest of the ti-from-task attributes. I see where you're coming from, "it's broken now for everything else, why fix it for this one" kind of thing. But letting things refresh willy-nilly 1) leads to an inconsistent behaviour during runtime (we hear from users/customers _all the time_ how much they hate Airflows inflight updates/changes after each parse) but sure I can buy that AIP-66 will address this in the future (hopefully?). But there is also the side effect of even looking at task instances. If you open the /task page for example, to view the attributes of a particular task instance/run, it actually calls refresh_from_task() ([here](https://github.com/apache/airflow/blob/15eedd080428314cf6e27443f91624459d17a77d/airflow/www/views.py#L1388)), which completely wipes/obscures what _actually_ happened for that task run and instead shows what the latest parsed task config is. So if you run a task with executor X (call that say TI 0) and then a month later you change the task (in the DAG code) to use executor Y, and then go back to just even look at TI 0 in the web UI it will call refresh from task and refresh TI 0 with the current attrs of the task as it was parsed last (this all updates the DB no less!). So now TI 0 will say it ran with executor Y, which is completely false (btw it took me ages to figure out what the hell was going on here when I wasn't getting the executors I expected in my testing). One of the direct call outs from folks reading AIP-61 was to be able to tell what executor a task ran with, and if we just go with the approach of do nothing and let airflow be airflow, that request will be dead on arrival. So it's just a little frustrating to hear push back on letting wonky stuff stay wonky. But alas, I'm out voted as it were, so I'll leave it be and we'll have to cover it in documentation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
