feat(infra): new workspace infrastructure setup

[ybezsonov]

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

In general, to fix this kind of problem you should avoid returning raw exception messages or stack traces to clients. Instead, return a generic, user-friendly error message (for example, “Unable to start threads at this time”) and log the detailed exception on the server side where it is available for diagnostics but not exposed.

For this specific controller, the best fix with minimal functional change is:

• Change tryStartThreads and tryStopThreads so that they no longer wrap e.getMessage() into the Failure record.
• Instead, log the caught IllegalStateException on the server (using a logger) and return a Failure with a generic, non-revealing error message, such as “Could not start threads” or “Could not stop threads”.
• Because we only see this file, we will add a logger in this controller using a standard logging utility that is likely already present in a Spring Boot app, such as SLF4J (org.slf4j.Logger / LoggerFactory).
• The public API (startThreads and stopThreads) will continue to behave similarly from the client perspective: on failure they still return 400 Bad Request with a human-readable message, but the content will be generic and not derived from the exception message.

Concretely:

• Add imports for org.slf4j.Logger and org.slf4j.LoggerFactory at the top of ThreadManagementController.java.
• Add a private static final Logger logger = LoggerFactory.getLogger(ThreadManagementController.class); field.
• Modify the catch (IllegalStateException e) blocks in tryStartThreads and tryStopThreads to call logger.error("... context ...", e); and return a Failure with a fixed message instead of e.getMessage().

In general, to fix information exposure via error messages in a REST controller, you should avoid returning raw exception messages to clients. Instead, return a generic, non-sensitive error description (e.g., “Unable to start threads”) and log the detailed exception message and stack trace on the server side for diagnostics.

For this file, the safest minimal change is:

• Introduce logging in ThreadManagementController (e.g., using org.slf4j.Logger and LoggerFactory).
• In tryStartThreads and tryStopThreads, catch IllegalStateException and:
  • Log the exception (including stack trace) with context.
  • Return a Failure with a generic error message that does not include e.getMessage().
• Keep the public API behavior (HTTP status codes, basic success messages) the same, only changing the content of error messages to be generic.

Concretely:

• Add import org.slf4j.Logger; and import org.slf4j.LoggerFactory; at the top of ThreadManagementController.java.
• Add a private static final Logger logger = LoggerFactory.getLogger(ThreadManagementController.class); field.
• In tryStartThreads, change return new Failure(e.getMessage()); to something like:
  • logger.error("Failed to start threads", e);
  • return new Failure("Unable to start threads at this time.");
• In tryStopThreads, change return new Failure(e.getMessage()); similarly:
  • logger.error("Failed to stop threads", e);
  • return new Failure("Unable to stop threads at this time.");
    This preserves the structure and HTTP semantics but prevents exposure of exception details.