Fix deploymentId not populating after locking

[wwillard7800]

Impact

• Bug fix (non-breaking change which fixes expected existing functionality)
• Enhancement/New feature (adds functionality without impacting existing logic)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

Fix issue: #4448
I spent a while trying to implement a FastCheckCommandStep class because the root cause really is we want to not lock the database if fastcheck reports we are up to date, but ending up stumbling on a number of issues relating to the different usages of the LockServiceCommandStep. Because the lock service step is so "low level" it doesn't really work to add the necessary parameters to support a fast check. I thought about implementing a FastCheckLockServiceCommandStep but just resolved I was getting in too deep and should be able to fix this in a few lines of code for now.

I'm not sure if FastCheckLockServiceCommandStep is the right move for the future or if we should choose some other route.

Things to be aware of

Things to worry about

Additional Context

[filipelautert]

Thanks! That's not the first time that this happens.. if I'm right before 4.21.0 we had a similar issue.

[MalloD12]

Hey @wwillard7800 / @abrackx , I'm seeing there is another call of:

Scope.getCurrentScope().getSingleton(ChangeLogHistoryServiceFactory.class).getChangeLogService(database).generateDeploymentId();

in AbstractFutureRollbackCommandStep. Should that one also be removed or is not used? I don't have all this command process super clear, but thought it might be worth checking with you.

Thanks,
Daniel.

[wwillard7800]

Hey @wwillard7800 / @abrackx , I'm seeing there is another call of:

Scope.getCurrentScope().getSingleton(ChangeLogHistoryServiceFactory.class).getChangeLogService(database).generateDeploymentId();

in AbstractFutureRollbackCommandStep. Should that one also be removed or is not used? I don't have all this command process super clear, but thought it might be worth checking with you.

Thanks, Daniel.

I believe that this call needs to be here. @abrackx do you agree?

[abrackx]

Hey @wwillard7800, I'm seeing there is another call of:

Scope.getCurrentScope().getSingleton(ChangeLogHistoryServiceFactory.class).getChangeLogService(database).generateDeploymentId();

in AbstractFutureRollbackCommandStep. Should that one also be removed or is not used? I don't have all this command process super clear, but thought it might be worth checking with you.

Thanks, Daniel.

Good catch but I believe this is irrelevant to the bug. future-rollback-<count/tag/etc>-sql commands only yield rollback scripts and do not touch (nor operate on) deployment id. As far as I know, the only times deployment id really come into play is when running an update.