[Fix-17854][Worker&SQL Task] Add sql task result alert from worker to master by rpc

[njnu-seafish]

Purpose of the pull request

close #17854

Brief change log

Add sql task result alert from worker to master by rpc

Verify this pull request

This pull request is code cleanup without any test coverage.

(or)

This pull request is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(or)

Pull Request Notice

Pull Request Notice

If your pull request contains incompatible change, you should also add it to docs/docs/en/guide/upgrade/incompatible.md

[njnu-seafish]

Hey @ruanwenjun @SbloodyS, whenever you have time, would you mind reviewing this fix to see if it looks reasonable? Really thanks a lot!

[ruanwenjun]

This seems unrelated to the task executor lifecycle, it is a feature of the SQL task.

If the Worker can load the alert plugin, it can send this notification itself. Maybe it's time for us to remove the AlertServer.

[njnu-seafish]

This seems unrelated to the task executor lifecycle, it is a feature of the SQL task.

If the Worker can load the alert plugin, it can send this notification itself. Maybe it's time for us to remove the AlertServer.

Hey, Can task result alerts be considered similar to the YarnAppId generated by a task—i.e., as additional auxiliary events occurring during the task's lifecycle?

Is the intention to deprecate the AlertServer role and migrate all alerting logic to the Worker? If so, note that Workers currently cannot access the database.

[ruanwenjun]

Hey, Can task result alerts be considered similar to the YarnAppId generated by a task—i.e., as additional auxiliary events occurring during the task's lifecycle?

Task results can be treated as part of the task execution context, but this should only store elements like the task result path. It is not suitable for storing SQL output. We should not store task outputs or similar content in the database, as this is highly non-generic, the output might very large.

Is the intention to deprecate the AlertServer role and migrate all alerting logic to the Worker? If so, note that Workers currently cannot access the database.

For such alerts, we do not need to persist them to the database.

[njnu-seafish]

Task results can be treated as part of the task execution context, but this should only store elements like the task result path. It is not suitable for storing SQL output. We should not store task outputs or similar content in the database, as this is highly non-generic, the output might very large.

To prevent excessive resource usage, the size of task result alerts must be constrained—just as we do with log output by limiting the number of displayed lines.

For such alerts, we do not need to persist them to the database.

Alert sending should be asynchronous to avoid blocking the main flow.
Without persistence, alerts could be lost—currently, all alerts are stored in the DB first, and the Alert service processes them from there.

[ruanwenjun]

Here, the alert should be sent synchronously rather than asynchronously.
Otherwise, if the SQL query succeeds but the alert fails, the upper layer cannot know.
If notification delivery fails in this scenario, the SQL execution will be meaningless.