I am trying to call procedure at 11pm everyday using mysql event but it is not occuring even the event schedular is ON. Anyone have a solution? i am using the following syntax.
CREATE EVENT deleteandprocess
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 23 HOUR)
DO
CALL deleteUnprocessCartItems();
SubDagOperator success is based on success state of the tasks within. Lately after Migration from Airflow 1.10 to Airflow 2, we have seen 2 instances which are not normal.
a) Scenario 1:
Total run duration shown for the subdagoperator is not the sum of the time taken by all the underlying tasks.
-- Underlying tasks took 1 hour to complete as per the GANTT chart but on hovering over SubdagOperator it shows 10 mins
b) Scenario 2:
Dag : Schedule to run at 12:50 am UTC on Sunday
Task1(BigqueryOperator) --> Task2(SubDagOperator) --> Task3(BigqueryOperator)
Task1>> Task2 >> Task3
Task2 has 3 tasks within it running it parallel, all of them using BigqueryOperator
Subtask1
Subtask2
Subtask3
Also Task2.Subtask1 uses one of the table as input from Task1
In ideal scenario first Task1 will complete before triggering the Task2 or any of its underlying subtasks.
Opposite to above we see from logs of Task2.Subtask1 that the task got triggered 2 minutes before the table in Task1 got created. Eventually failing the Task2.Subtask1 with input table not found.
Are the tasks within SubdagOperator treated differently in Airflow 2.
Note : We have 2 schedulers in Airflow 2. Is it something to do with commnunication gap between schedulers
I have a custom recurring reminder (recurring every 2 weeks) named "Recycling is every other Monday". And I wrote a script to catch change events and record the next due date of selected reminders.
(Note, I chose to do this using Apple's sqlite3 database because the size of my DB is so large, it takes upwards of 30 second to run via applescript and takes a fraction of a second using sqlite3).
When I query the database to get all incomplete reminders and all reminders modified since a specific date, I ran into a use case where if I had accidentally "uncompleted" (and recompleted) a very old instance of the recurrence and also accidentally completed and "uncompleted" the current instance, I cannot seem to figure out the logic to figure out the next due date (which is called the "remind me date" in applescript and the reminders app).
Here is my query and the output, looking at all incomplete reminders and any reminder modified in the past 14 days. (Note, if I take out ALL the WHERE clauses, this output comprises the last few rows of all output).
% sqlite3 "file:/Users/robleach/Library/Reminders/Container_v1/Stores/Data-A6A78E21-BA53-4867-B651-08569C902142.sqlite?mode=ro" -cmd ".mode tabs" "SELECT (978307200 + TASK.ZLASTMODIFIEDDATE) as lmdEpochSecs, TASK.ZPRIORITY AS priority, replace(replace(replace(TASK.ZTITLE1, X'0A', '\n'), X'0D', '\r'), X'09', '\t') AS title, LIST.ZNAME1 AS list, replace(replace(replace(TASK.ZNOTES, X'0A', '\n'), X'0D', '\r'), X'09', '\t') AS notes, TASK.ZCOMPLETED as completed, strftime('%Y-%m-%dT%H:%M:%S',(978307200 + TASK.ZCOMPLETIONDATE),'unixepoch') as completionDate, strftime('%Y-%m-%dT%H:%M:%S',(978307200 + TASK.ZCREATIONDATE),'unixepoch') as creationDate, TASK.ZDISPLAYDATEISALLDAY as isAllday, strftime('%Y-%m-%dT%H:%M:%S',(978307200 + TASK.ZDISPLAYDATEDATE),'unixepoch') as displayDate, strftime('%Y-%m-%dT%H:%M:%S',(978307200 + TASK.ZLASTMODIFIEDDATE),'unixepoch') as modificationDate, TASK.ZFLAGGED as flagged, TASK.ZCKIDENTIFIER as reminderID, strftime('%Y-%m-%dT%H:%M:%S',(978307200 + TASK.ZACKNOWLEDGEDDATE),'unixepoch') as ackDate, strftime('%Y-%m-%dT%H:%M:%S',(978307200 + TASK.ZENDDATE),'unixepoch') as endDate, strftime('%Y-%m-%dT%H:%M:%S',(978307200 + TASK.ZDUEDATE),'unixepoch') as dueDate, strftime('%Y-%m-%dT%H:%M:%S',(978307200 + TASK.ZSTARTDATE),'unixepoch') as startDate FROM ZREMCDOBJECT TASK LEFT JOIN ZREMCDOBJECT LIST on TASK.ZLIST = LIST.Z_PK WHERE LIST.Z_ENT = 21 AND LIST.ZMARKEDFORDELETION = 0 AND TASK.ZMARKEDFORDELETION = 0 AND (TASK.ZCOMPLETED = 0 or modificationDate > '2021-08-03T09:25:08') ORDER BY CASE WHEN TASK.ZDISPLAYDATEDATE IS NULL THEN 1 ELSE 0 END, TASK.ZDISPLAYDATEDATE, TASK.ZPRIORITY;" | grep "Recycling is " | sort -n | perl -e 'while(<>){chomp;#x=split(/\t/);$x[0]=localtime($x[0]);print(join("\t",#x),"\n")}'
lmd priority title list notes completed completionDate creationDate isAllday displayDate modificationDate flagged reminderID acknowledgedDate endDate dueDate startDate
Sun Aug 8 21:57:44 2021 0 Recycling is every other Monday ToDo Home Recurring 1 2021-08-09T01:57:44 2017-09-18T16:59:00 0 2021-08-08T22:00:00 2021-08-09T01:57:44 0 AA6C3A21-45F8-4A21-8A29-E20F00C6EFE3 2021-08-08T22:00:00 2021-08-09T04:00:00
Sun Aug 8 21:58:33 2021 0 Recycling is every other Monday ToDo Home Recurring 1 2021-08-09T01:58:33 2017-09-18T16:59:00 0 2021-08-22T22:00:00 2021-08-09T01:58:33 0 E324BFD0-4EC8-41D3-8EF2-0BEA96EC05F0 2021-08-22T22:00:00 2021-08-23T04:00:00
Sun Aug 8 21:58:33 2021 0 Recycling is every other Monday ToDo Home Recurring 0 2017-09-18T16:59:00 0 2021-09-05T22:00:00 2021-08-09T01:58:33 097F85B66-E979-5226-9E87-794C0901AEB2 2021-09-05T22:00:00 2021-09-06T04:00:00
Sun Aug 15 09:19:03 2021 0 Recycling is every other Monday ToDo Home Recurring 1 2021-08-15T13:19:03 2017-09-18T16:59:00 0 2017-07-17T00:00:00 2021-08-15T13:19:03 0 EAA3CD20-D4A7-59F6-B3BF-DD7A32175810 2017-07-17T00:00:00 2017-07-17T04:00:00
Sun Aug 15 12:53:31 2021 0 Recycling is every other Monday ToDo Home Recurring 1 2021-08-15T16:53:31 2017-09-18T16:59:00 0 2121-07-15T22:00:00 2021-08-15T16:53:31 0 0CBB413B-7BD2-4D4E-80EF-612BF08E2DAD 2021-08-08T22:00:00 2021-08-09T04:00:00
I added headers manually for convenience. The output is sorted by lmd (last modified date), the most recently modified at the bottom.
The actual remind me/due date of the only incomplete instance of the reminder in the reminders app is 2021-08-22. That date does occur among the rows returned (2nd row). But my script is yielding 2121-07-15, which is the due date of the row with the most recent lmd.
My script normally records the due date (or display date - always appear to be the same) of the last modified entry as the next due date, and this is usually correct, but in this instance, it's wrong. And I cannot seem to discern the logic of how Apple determines what the remind me date actually is. The row containing the correct due date has a completion status of "completed", so if I took that row, the completed status would be wrong. The only row with an incomplete status has a due date that is 2 weeks after the correct due date.
I output I want to generate for the reminder would be:
Sun Aug 15 12:53:31 2021 0 Recycling is every other Monday ToDo Home Recurring 0 2017-09-18T16:59:00 0 2021-08-22T22:00:00 2021-08-09T01:58:33 0 E324BFD0-4EC8-41D3-8EF2-0BEA96EC05F0 2021-08-22T22:00:00 2021-08-23T04:00:00
however, the only data I'm really interested in is the completed status (being 0) and the due date (/remind me date) reflecting what the Reminders app shows (2021-08-22).
So how do I compile the correct combined current entry from this output? I don't get it.
UPDATE: I was looking at the output this morning again to try and work out the logic, so I ran the command again and saw a new entry that didn't make sense. The latest (new) version of the reminder had a new due date of 9/5/2021. I checked my phone because I didn't remember completing the latest reminder and the phone still shows the due date as 8/22/2021. That got me thinking, so I checked the reminders app on the computer on which I was running the sqlite3 query and sure enough, the remind me date showed 9/5/2021. It disagreed with my phone on the same iCloud account! So I think that this appears to possibly be an iCloud synch bug. I wish I'd checked it when it said the due date was 7/15, but I bet that's what it said. My guess is that my accidentally changing the completion status of 2 instances of the recurrence lead to reveal a synch bug. So I disabled reminders synch on the Mac mini and reenabled it. Reminders are syncing from scratch. I'll report back once I've confirmed my suspicion. I bet they'll agree once the synch is finished.
Turns out the latest remind-me-date(/due date) does appear to be in the most recently modified reminder entry in the sqlite database.
The problem appears to have been an iCloud Reminders synch issue(/bug).
I had been consulting the remind-me-date in the reminders app on my iPhone, which showed a date of 8/22/2021, but when I opened the Reminders app on the computer on which I was running the sqlite command, the remind-me-date did not agree with my iPhone's copy of the recurring reminder.
Both devices were using the same iCloud account. I resolved the discrepancy by turning off reminders synch and turning it back on. The synch took awhile, but once it was finished, the remind-me-date agreed with the one on my iPhone, and the sqlite command showed the same due date in the most recent version of that reminder.
I think that the reminder modifications that lead to the synch issue were:
Accidental "uncompletion" of an old previously completed reminder followed by a "re-completion"
Accidental "completion" of the latest version of the reminder followed by an "uncompletion"
...though I'm not certain of the order in which those happened.
I suspect that the iCloud Reminders synch may have incorrectly condensed those multiple edits into a single event, though...
The bad copy of the reminder did seemingly updated on its own sometime this morning (which I know because I have fswatch set up to watch the database file and text me when it detects a change to a reminder I'm tracking for automations), resulting in a second incorrect due date (9/5/2021) that still disagreed with my phone's due date of 8/22/2021.
The problem with changing the day of the week to reload heroic instances.
It's always Friday at 04:00.
I am trying to put in the config in the line:
Instance.ResetTimeRelativeTimestamp =
one of the other dates:
1552867201 = 18.03.2019 00:01 Monday
1552953600 = 19.03.2019 00:00 Tuesday
1553040001 = 20.03.2019 00:01 Wednesday
1552521601 = 14.03.2019 00:00 Thursday
1552608001 = 15.03.2019 00:01 Friday
1552694401 = 16.03.2019 00:01 Saturday
1552780801 = 17.03.2019 00:01 Sunday
Then I've cleared 3 tables in characters DB:
instance_reset
character_instance
instance
When I start the server - I see the same result - restart on Friday at 4:00.
Question: How to change the day of week? It must be Wednesday.
I actually just finished figuring this out myself. After much digging through the AzerothCore source, and it looks like the day of the week that instances are reset is chosen the very first time the server is started. As far as I can tell, ResetTimeRelativeTimestamp is not used to determine reset times. To be more specific:
The server starts up and starts to load instance reset times from the characters.instance_reset table
If an instance is missing an entry in the instance_reset table, an entry is added using the following formula:
Reset time = today(in UTC, rounded to nearest day) + RaidDuration(from mapdifficulty_dbc, named resetTime in code) + Instance.ResetTimeHour(from worldserver.conf)
Let's run through an example
You're in the US Central time zone, which is currently UTC-5. It's 2020_10_18 14:56:23, Convert that to UTC and you get: 2020_10_18 19:56:23. Round to the nearest day and you get UTC 2020_10_18 00:00:00
Let's say it's setting the reset time for ICC 10 man. If you look in mapdifficulty_dbc, RaidDuration is 604800 seconds, which is 7 days.
Let's say you have Instance.ResetTimeHour set to the default value, 4. This becomes 4 hours.
Plug this all in and you get resettime = 'UTC 2020_10_18 00:00:00' + 7 days + 4 hours = UTC 2020_10_25 04:00:00, a Sunday. Convert back to US Central time and you get: 2020_10_24 23:00:00 CST, a Saturday. Instances will reset on Saturday
The next time the instance is reset, its next reset time is reset using previous reset time + RaidDuration.
This means that if you want to choose the day of the week, you need to do one of the following:
Modify the instance reset times in the instance_reset table to be on the day of the week that you want. This approach is risky as it involves manipulating the reset timestamps in the DB directly
Empty the instance table, then start the server on the day you want instances to reset. Yes, this still involves DB manipulation, but at least the contents of the table are generated by Azeroth Core instead of yourself.
Here's what I did to solve the issue
The reason I've buried this so deeply in the answer is that you have to understand what you're doing before you start wiping out tables in your database. PROCEED WITH CAUTION.
Shut down the worldserver
Empty the characters.instance_reset table via SQL
Set your system time to some time before the current time that when converted to UTC falls on the day of the week you'd like instances to reset
Start the worldserver. Wait for it to load. Login and confirm that instance lockouts are expiring at the correct time.
Shut down the worldserver
Set your system time back to the correct time and start the server back up again
Job A runs Mon-Fri and triggers job B. However, I want Job B to run every day. How can I ensure Job B runs on Saturday and Sunday, even though it is set up to only run after Job A completes?
What we did for the similar issue is we created a job that rolls in only on weekends. This job might not have any IN-condition or can be timer dependent.
Let's call this job 'JOB_WEEKEND'.
JOB_WEEKEND out condition:
JOB_WEEKEND-OK
Now the Job B should have these conditions
JOB A-OK or JOB_WEEKEND_OK
This you can select from 'IN conditon relationships' below the conditions tab. This weekend job can be used for any other similar jobs too.
If you are using Control-M version 8, then you can use adjust condition option by using smart folders instead of creating a new dummy job.
You just need to give '#' before the IN condition of job B for Job A as below:-
IN #-JOB A--JOB B
while giving this condition, it means that job B will wait if there is a job A (from Mon- Fri). However, on weekend (SAT & SUN) the job B will not wait for Job A.