> On 26 Feb 2026, at 6:38 PM, Peter Xu <[email protected]> wrote:
>
> On Thu, Feb 26, 2026 at 09:16:43AM +0530, Ani Sinha wrote:
>>
>>
>>> On 25 Feb 2026, at 10:59 PM, Peter Xu <[email protected]> wrote:
>>>
>>> Hi, Ani,
>>>
>>> On Wed, Feb 25, 2026 at 09:19:40AM +0530, Ani Sinha wrote:
>>>> Currently the code that adds a migration blocker does not check if the same
>>>> blocker already exists. Return an EEXIST error code if there is an attempt
>>>> to
>>>> add the same migration blocker again. This way the same migration blocker
>>>> will
>>>> not get added twice.
>>>
>>> Could you help explain why it will inject two identical errors in the first
>>> place, and why the caller cannot make sure it won't be injected twice?
>>
>> Likely due to a bug in the code. For example if the init function that
>> adds the blocker is called again and the caller does not handle the
>> second init call properly. This came up as a part of the coco reset work
>> where migration blockers are added in init methods. They need not be
>> added again when init methods are again called during the reset
>> process. The caller can handle it of course but adding a check further
>> down the call stack makes things more robust.
>
> IMHO if we want to make it more robust, we shouldn't return an error
> because the caller may not always check for errors.
>
> Would assertion suites more here? Because migration blockers are not
> something the user can manipulate, so it's a solid bug to fix when
> triggered.
If Prasad agrees, I will send something.
>
> Thanks,
>
> --
> Peter Xu
