Skip to content

Fixed the issue where the process table was completed after AMS restart, but the table status remained in the running state.#4043

Open
lintingbin wants to merge 2 commits intoapache:masterfrom
lintingbin:fix/table_always_running_after_pod_restart
Open

Fixed the issue where the process table was completed after AMS restart, but the table status remained in the running state.#4043
lintingbin wants to merge 2 commits intoapache:masterfrom
lintingbin:fix/table_always_running_after_pod_restart

Conversation

@lintingbin
Copy link
Contributor

Why are the changes needed?

Close #4041.

Brief change log

  • Initialize the TableOptimizingProcess to retrieve the Process Status from the database instead of using the default RUNNING status.
  • In the initTableRuntime, determine whether the Process Status is successful. If successful, perform the complete process operation.

How was this patch tested?

  • Add some test cases that check the changes thoroughly including negative and positive cases if possible

  • Add screenshots for manual tests if appropriate

  • Run test locally before making a pull request

Documentation

  • Does this pull request introduce a new feature? no
  • If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

@github-actions github-actions bot added the module:ams-server Ams server module label Jan 15, 2026
Copy link
Member

@klion26 klion26 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lintingbin Thanks for the contribution, the change all over looks good to me, let one minor comment, please let me know what do you think.

mapper -> mapper.getProcessState(tableRuntime.getProcessId()));
process = new TableOptimizingProcess(tableRuntime, meta, state);
tableRuntime.recover(process);
if (process.getStatus() == ProcessStatus.SUCCESS) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will place this logic in tableRuntime.recover(process) be better?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense, I've made the changes

Copy link
Member

@klion26 klion26 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the quick update, LGTM, will merge it in next week if there are no more comments from the community.

Comment on lines 142 to 143
process = new TableOptimizingProcess(tableRuntime, meta, state);
tableRuntime.recover(process);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@klion26 Do you know why there is also tableRuntime.recover in the initialization function of TableOptimizingProcess? It looks a bit strange, doesn't it? Maybe we should optimize it?

      if (this.status != ProcessStatus.KILLED) {
        tableRuntime.recover(this);
      }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

module:ams-server Ams server module

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Restarting AMS may cause the table to remain in the running state indefinitely and never transition to another status.

2 participants