fix: UIServer.close() should await HTTP server shutdown

[jeffspahr]

Problem

UIServer.close() calls this.httpServer.close() but doesn't wait for the server to actually finish closing:

// app.ts:86
close() {
  if (this.httpServer) {
    this.httpServer.close();  // async, but not awaited
  }
  this.httpServer = undefined;
  return this;
}

http.Server.close() is asynchronous — the OS doesn't release the port immediately. This causes EADDRINUSE errors in tests when tests run back-to-back, because the previous server's port hasn't been released yet.

Current Workaround

Tests now use supertest(app.app) (passing the Express application directly) instead of supertest(app.start()) (passing the listening HTTP server). This lets supertest create ephemeral servers on random ports, avoiding the port conflict entirely.

Suggested Fix

Make UIServer.close() return a Promise that resolves when the server is fully closed:

close(): Promise<void> {
  return new Promise((resolve, reject) => {
    if (this.httpServer) {
      this.httpServer.close((err) => {
        this.httpServer = undefined;
        if (err) reject(err);
        else resolve();
      });
    } else {
      resolve();
    }
  });
}

This would also benefit production graceful shutdown scenarios.

Context

Discovered during the Jest → Vitest migration (PR #12756). With done callbacks, the timing gap between tests masked the issue. With async/await, tests chain faster and expose the race condition.

[github-actions]

🎉 Welcome to the Kubeflow Pipelines repo! 🎉

Thanks for opening your first issue! We're happy to have you as part of our community 🚀

Next steps:

• Check out the Contributing Guide for repo-specific guidelines and the Kubeflow Contributor Guide for general community standards
• Join our #kubeflow-pipelines Slack channel
• Attend the Kubeflow Pipelines WG meetings

Feel free to ask questions in the comments.

[aryawwn21]

The problem arises because of the reappearance of the defaults at a later stage in the flow of execution, even when a correct user-supplied value is already present. This results in the explicit configuration being overridden silently without any warning or error message.

This problem can be resolved without removing any of the existing logic by modifying the application of the defaults as follows:

• Before assigning any default or computed value, check whether the user has already supplied a value.
• Apply the defaults only if the corresponding user input is absent.
• Maintain the existing functionality when no user value is supplied, so that existing pipelines are not affected.

An optional non-blocking warning can be introduced when a default is applied despite the presence of related user input, to make this point clear and easier to debug.