potiuk commented on issue #14529:
URL: https://github.com/apache/airflow/issues/14529#issuecomment-1132842410
There are two major differences:
* environment where the command runs
* mechanism of feedback to the user when there are problems.
In this case again you have human running the command and terminal where the
operation is run (and human overlooking and reacting it) rather than webserver
UI.
Webserver - almost by definition handles short "requests". While in terminal
you can run long tasks because - well - you have an open terminall - that
serves as the environment where the job runs. Then you have also a feedback
mechanism - you can print logs and errors to the user and let the user read the
logs and manually decide how to react on those problems. You can see that this
and that manual task failed and run manual commands that will fix the problem.
It's a super-low level interface that requires constant attention and possibly
follow-up manual remedy of any problems that will arise.
In Webserver UI this is a completely different story. You expect to send a
request ("clear") and then something should do it - you will not stare at the
terminal and logs, you will likely close the browser or move to another screen
when you request such operation to happen if it takes more than a second or
two. this is how web UI works.
And in order to do that you need ot implement much more:
*process that actually runs the long term operation (most web solutions and
HTTP connection will have a time limit on running a single request and runnign
a request that waits for some time is not good
* this process is likely not going to run in your browser (unlike the
terminal command) because of the nature of browser UI
* when it fails you really need to notify they user somehow (because the
user will likely be already somewhere else or maybe evne close the browser in
the meantime
* when there are errors you need to know what kind of errors there will be
and give the user an opportunity to fix them or acknowledge that the problem
does not need fixing - sending logs is useless because that would mean that the
user will have to manually react on any log -entry - which means finding the
right task and performing an action. So you need to implement the whole
mechanism of communicating with the user and allowing the user to react to
problems that might happen. If you have one or two tasks, this seems easy, but
when you have 100s or 1000s tasks then such "request" can take many minutes to
complete and produce 100s or thousants of errorrs to deal with, so you have to
prepare a solution that will let the user effectively deal with those if you
want to make into a "proper UI" feature.
From In the command line it's perfectly fine to tell the users - "those are
logs of your command - deal with it" . In the UI, you need to implement proper
UI for that.
This is precisely why we have no "backfill" implemented in the UI - only as
a command line.
And @asitstands - if you think that things are easy - there is nothing to
prevent you from implementing it. Feel free. It's very easy to tell that
something is "easy" and ask otehrs to do that, and very different thiing to
implement it itself. Airflow has more than 2000 contributors and anyone can
contribute anything - providing that it will pass the review.
In this case - until all the problems and paths of processing are not solved
the change will not be accepted. But if you implement, test and prove that all
of this is fine and that our users will get a great tool to manage multiple
(sometimes 100s sometimes 1000s entities). I am super happy to accept such
change.
--
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]
