New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CronSchedule workflow stop #1829
Comments
This is another issue. It stopped running for a while in the middle.
the history of c6035d88-68f4-4297-81c8-9a12c235cb19 :
the history of 77a21fb5-e8e7-4549-9f62-b4ddcb309aad is
|
I think there's a good chance that the fixes in 1.11.4 will also fix this issue. Could you try with that and see if you can reproduce this behavior? Unfortunately it's pretty hard to tell what's going on just from the mysql tables since there are quite a few levels of abstraction above that. It's probably more useful to examine the history events with the web ui or tctl. A cron workflow will be "started" immediately but its first task won't be scheduled until it's time to run (that's the |
Hi,I try again with 1.11.4 , Can reproduce。
the history info :
the history info of 568a4c35-5939-4235-b26a-b9a651517835 :
What other information needs to be provided? |
Did not run for a while
the history of 3f54a3a7-4349-4c87-a080-1ddaa4eb3d4a
the history of 7897ce00-c41d-4403-94c7-569f2320ebe2
|
Could you include timestamps with the history ( |
yes, i sorry, The above content is wrong , the second history is for the history for temporal_cron1_retry_bc38af7f-1999-4c2f-9019-b75602bb77e2 workflow was cleared by me , here is another one for you
the history for 29ed2dea-95a2-4898-ad8b-ceeb80f69493 :
the history for ba6cee25-303b-4f4b-bc59-bfc40133aa95 :
|
this is Workflow information that is no longer running。
the history for temporal_cron2_retry_20ee8b07-60f4-4a7f-b5a6-8871722177e1 without --run_id :
the hitroy for 14c62b11-9004-4664-b8fa-fec096ad5c53 :
|
It looks like something is going wrong with the worker picking up workflow tasks. E.g. in We're trying to figure out how to reproduce this behavior to understand what's going on. Could you give us some more details about how you've set things up? Specifically:
One more bit of info that might help is to run
while it looks like things are stuck, to check that the worker is actually polling on the task queues. The main task queue name is the one that you configured your worker with. The sticky name looks like |
I have recently been looking at the code related to the temporal server, hoping to find out the corresponding problem, the code has not been understood yet, is there any detailed documentation? main_task_queue_name info:
sticky_task_queue_name info :
|
I found the problem. When the task was inserted into the tasks table, the return was successful, but the data was not written successfully, which resulted in the subsequent read failure. There is no such problem after changing the database |
@zydovech, could you help us understand this a little bit more? |
i'm so sorry,missed your information,and didn't reply timely,It's a simple mistake. the database , read and write separation. that caused the successful write is not read immediately . I did not update the above reply in time |
@zydovech thanks for the update. Resolving the issue now. |
I run cron job ,After running for a period of time, the worker cannot get the corresponding task。
The last two tasks are:
the history of temporal_cron1_687ddd07-6e99-4c1b-96ed-f321979a0c85 is :
the history of runid 8db0f3db-96e4-4908-be09-bc7a401c4315 is :
Updated relevant information
Steps to Reproduce the Problem
just run workflow with CronSchedule, in my case , I ran ten of them, and after a while, only 7 were left
Specifications
The text was updated successfully, but these errors were encountered: