Max,
Yes, the stack trace points to the race condition issue. What can be done
to fix this? Can someone from the dev team look into this? Should I raise a
JIRA for the same?
On 2 November 2018 at 11:14:36 AM, Maxime Beauchemin (
maximebeauche...@gmail.com) wrote:
Wait, the title of this
Wait, the title of this thread is "Duplicate key unique constraint error",
to me that screams that something is not ok. If the check+insert was atomic
(insulated) this error wouldn't happen. Also I'm pretty sure when I looked
the stack trace looked like a scheduler-specific stack trace. It may be
Max,
If check+insert works correctly, then even multiple instances of scheduler
running in parallel should not throw this error. I am not sure then when
can this error happen.
On 2 November 2018 at 8:37:20 AM, Maxime Beauchemin (
maximebeauche...@gmail.com) wrote:
The scheduler should never
The scheduler should never fail hard. The schedule logic that tries to
insert the new task instance should only insert a new one if it doesn't
exist already and isolate that check+insert inside a database transaction.
Max
On Fri, Nov 2, 2018 at 5:38 AM Abhishek Sinha wrote:
> Brian,
>
> We use
Brian,
We use the trigger dag CLI command to trigger it manually.
Even when you have custom operators, the duplicate key error should not
happen right? Shouldn't the combination of task id, dag id and execution
date be unique?
On 30 October 2018 at 10:23:27 PM, Abhishek Sinha
