fix(cluster_family): Cancel slot migration from incoming node on OOM

[mkaruza]

If applying command on incoming node will result in OOM (we overflow
max_memory_limit) we are closing migration and switch state to FATAL.

[BorysTheDev]

looks like incorrect place for this logic

[mkaruza]

If FLOW fails with C_FATAL we'll call it, where would you put migration->Stop to handle stopping of migration?

[BorysTheDev]

Maybe we can move it to reportError or SetState, where we set the fatal status

[adiholden]

@kostasrim Please review the changes in this PR related to the reply builder

[kostasrim]

@kostasrim Please review the changes in this PR related to the reply builder

I synced with @mkaruza internally. We don't need the changes in the reply builder as they affect a broader part of the codebase. What is more is that the common denominator for all errors are strings and not op status codes.

What we need here is to fetch out the error message on the caller side (of DispatchCommand) on a one very specific code path (when status code is OOM). This can be done easily by an extra std::optional<bool> within ConnetionContext and pretty much get rid of all of the changes in ReplyBuilder. If we have an error and if std::optional is emplaced and if the string is kOOM we set the boolean to true and that's how the caller knows. No changes to reply builder and no generic solution for a non generic problem. Furthermore, no extra overhead unless we are actually on this very specific flow (and IMO the 10 byte comparison of the string is nothing)

If we ever need a generic solution that on error requires to return the actual error message to the caller, we just add an extra argument to DispatchCommand() and do it properly.

[BorysTheDev]

can we put is_oom_ into command context?

[mkaruza]

CommandContext will be create in DispatchCommand so not available from incoming slot migration.

[BorysTheDev]

Maybe we can do refactoring and propagate it? I'm ok to do this in separate PR if it is possible

[mkaruza]

OK, let's talk to improve this in separate PR

[kostasrim]

I don't want to push any refactor for a single flow. As I wrote above, let's not rush generic solutions for non generic problems. When the time comes and we need the callers to check for reply builder errors we can discuss. Until then, sayonara as we have more important things to deal with.

[BorysTheDev]

@mkaruza Could you create a ticket to not forget regarding this refactoring

[adiholden]

Guys, valid points on both sides.

I agree that is_oom_ is conceptually tied to the command rather than the connection, so placing it in CommandContext makes sense from a design perspective. However, since CommandContext isn’t available during the incoming slot migration, I support the idea of deferring this to a separate PR . I will follow up with Mario to understand the effort and if we want to do this If this is a big change and the proposed refactor is non-trivial .

[kostasrim]

we don't discuss reply builder errors. store OOM result in connection_context isn't logically correct,

I can argue the other way but this is not my point. My point is that we have other more important things to deal with rn than this refactor.

I am not the one who steers product direction or what to prioritize but I would ask first before considering this.

[adiholden]

I think @BorysTheDev raised a design concern. His suggestion to handle it in a separate PR seems reasonable and doesn't block this one.

The point about broader priorities is important, but I don't think it conflicts with acknowledging and tracking design inconsistencies. It’s not about shifting priorities now, but recognizing a spot where the design could be improved.

[adiholden]

LGTM