Re: [PR] [Fix-17817] [Master] Fix workflow timeout alerts failed [dolphinscheduler]

Thu, 12 Mar 2026 23:04:31 -0700 


njnu-seafish commented on PR #17819:
URL: 
https://github.com/apache/dolphinscheduler/pull/17819#issuecomment-4052982633

   > > > > > In DolphinScheduler 3.4.1, when both "Timeout Alert" and "Timeout 
Failure" are selected in the timeout policy settings, only the alert is sent, 
but the task does not fail as expected. Will this be fixed later?
   > > > > 
   > > > > 
   > > > > Task timeout fail bug is fixed by this PR: #17818
   > > > 
   > > > 
   > > > Has this issue been fixed in 3.4.1? I set up timeout failure for 
stored procedure tasks in DolphinScheduler 3.4.1, but it's not working as 
expected. @njnu-seafish
   > > > <img alt="image" width="922" height="645" 
src="https://private-user-images.githubusercontent.com/26373423/562673244-0aa1d218-a836-4ffc-a3e8-62ae5e11f54a.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzMzNjk3MDMsIm5iZiI6MTc3MzM2OTQwMywicGF0aCI6Ii8yNjM3MzQyMy81NjI2NzMyNDQtMGFhMWQyMTgtYTgzNi00ZmZjLWEzZTgtNjJhZTVlMTFmNTRhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjAzMTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwMzEzVDAyMzY0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWEyNWJkMTBhMjMwOTdmMjJjMWVlNzNlNTU4NDI1YzI4MzZmOTEzNzRkODQ3YTI1NGM5OGY3N2RiOWFhNWE1YWEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.1031WCWE2kRtfOEih4PWyudZNLfMR1HZw0eUreZv3SE";>
 <img alt="image" width="907" height="523" 
src="https://private-user-images.githubusercontent.com/26373423/562673545-45de6913-686a-4fcc-82db-7746ce4bd9ee.png?jwt=
 
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzMzNjk3MDMsIm5iZiI6MTc3MzM2OTQwMywicGF0aCI6Ii8yNjM3MzQyMy81NjI2NzM1NDUtNDVkZTY5MTMtNjg2YS00ZmNjLTgyZGItNzc0NmNlNGJkOWVlLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjAzMTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwMzEzVDAyMzY0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPThjN2IzYzhhNzQxYzQyMDhlMWNiMzk0MmE5NzI5MWIwMGQ0NDU4MzNjZjAzNTlhMDAwYjA2OTRhZjgyNjRlNzQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.XdFg4l305w3ujdgI-OCdKdCzjVvIUwoO5xkOqPAwZSY">
 <img alt="image" width="629" height="779" 
src="https://private-user-images.githubusercontent.com/26373423/562677119-f2ab9340-524c-467e-b5b6-d93fef4d2d0f.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzMzNjk3MDMsIm5iZiI6MTc3MzM2OTQw
 
MywicGF0aCI6Ii8yNjM3MzQyMy81NjI2NzcxMTktZjJhYjkzNDAtNTI0Yy00NjdlLWI1YjYtZDkzZmVmNGQyZDBmLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjAzMTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwMzEzVDAyMzY0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTE4ZGViNDU3MjEzMzBmNmZhZDNmMzc3M2U0ZjE3Y2UwZWE2NzllNDE1ZDJkYTJkZjYxZjgzZTdjMTExZjgxMzAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.9PEXlaJXAe2rmnDEua_6U97_AA_B4sNP_Zssjpm_GuI">
 <img alt="image" width="1260" height="501" 
src="https://private-user-images.githubusercontent.com/26373423/562676166-6d8adf7f-dace-43d4-8211-b8c324f04fa6.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzMzNjk3MDMsIm5iZiI6MTc3MzM2OTQwMywicGF0aCI6Ii8yNjM3MzQyMy81NjI2NzYxNjYtNmQ4YWRmN2YtZGFjZS00M2Q0LTgyMTEtYjhjMzI0ZjA0ZmE2LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFW
 
Q09EWUxTQTUzUFFLNFpBJTJGMjAyNjAzMTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwMzEzVDAyMzY0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTI3OTIyMjE1MmIxNTNjOTc5MzgzNzI5OTVjZDg4NzlkNWUyMThkZTg1YWJkNzg4YjdiMjJjMzM5NDIwYWFiNWQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.A4-zs6SmaV-zvKT96XrUWVQZ3TMnt27-KiINPkp_QfU">
 <img alt="image" width="1424" height="119" 
src="https://private-user-images.githubusercontent.com/26373423/562673446-dbcb28ce-4781-4bba-88cd-dfc180c8f2d4.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzMzNjk3MDMsIm5iZiI6MTc3MzM2OTQwMywicGF0aCI6Ii8yNjM3MzQyMy81NjI2NzM0NDYtZGJjYjI4Y2UtNDc4MS00YmJhLTg4Y2QtZGZjMTgwYzhmMmQ0LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjAzMTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwMzEzVDAyMzY0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWQzZmFi
 
MWY3Yzc3MWYwM2YzZjc0NWJhN2EwYmJhZGY1MDY5MWU2ODM3YmIyNmEzMmI1MzBlMTMxODRkMjhmNzkmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.xaP_57smBl68PvelbbN0RECFUgCzWtRcdFEMzM7eqGM">
   > > > Looking at the execution logs of the stored procedure, the following 
content is present:
   > > > ```
   > > > 2026-03-13 10:00:13.781 INFO  - setSqlParamsMap: Property with 
paramName: value1 put in sqlParamsMap of content call 
aSP_test20260204(null,null,${value1}); successfully.
   > > > 2026-03-13 10:01:13.783 INFO  - Try to cancel this procedure task
   > > > 2026-03-13 10:01:13.791 INFO  - This procedure task was canceled
   > > > 2026-03-13 10:02:44.029 INFO  - out parameter varchar key : value1 , 
value : 0
   > > > ```
   > > > 
   > > > 
   > > >     
   > > >       
   > > >     
   > > > 
   > > >       
   > > >     
   > > > 
   > > >     
   > > >   
   > > > So does the timeout failure strategy only cancel the execution of the 
stored procedure, rather than changing the status of this node to "failed"? I 
am wondering whether this is a bug or a software feature.
   > > 
   > > 
   > > Other Task Type timeout is ok? The logs indicate that the timeout 
cancellation logic was triggered; however, it appears the stored procedure 
failed to cancel successfully.
   > 
   > Other tasks work fine, but stored procedures with SLEEP cannot be stopped 
at all—this is likely a database-specific behavior.
   
   Both SqlTask and ProcedureTask may fail to respond to interruption signals 
under certain circumstances. Specifically, the database can enter an 
'uninterruptible' state where even simple SQL statements become atomic 
operations during specific execution phases, preventing them from responding to 
cancellation requests immediately.


-- 
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]

Reply via email to