aglinxinyuan opened a new issue, #7612: URL: https://github.com/apache/texera/issues/7612
### Task Summary `amber/src/main/scala/org/apache/texera/web/ComputingUnitMaster.scala` sits at **6.5% of 93 lines**. It is the entry point that assembles the whole service — JWT auth and the session-user value factory, the session handler, the websocket upgrade filter, the request log, every resource registration, and the recurring cleanup of expired execution results — and almost none of that is verified. Entry points here are **not** conventionally excluded, contrary to an older note: sibling Dropwizard entry points already have merged specs driving `run()` against a mocked `Environment`, one of them in #7561. One thing does differ from those siblings and is worth knowing before starting: **a Mockito `Environment` is not sufficient here.** `WebSocketUpgradeFilter.configureContext` needs a live `MutableServletContextHandler`, so `run()` has to be driven against a real `Environment`. Once it is, the whole method executes outside a server, including `scheduleRecurringCallThroughActorSystem`, which needs only `_actorSystem.scheduler`. Two hazards, both real and both worth writing down: 1. **`run()` repoints the JVM-wide `SqlServer` singleton** at `StorageConfig.jdbcUrl`, and `initConnection` **closes the pool it replaces**. A suite must point it back at its own embedded database before shutting down, or it leaves the singleton aimed at production storage for whatever runs next. 2. **amber sets neither `Test / fork` nor `Test / parallelExecution := false`**, unlike every other module that mixes `MockTexeraDB` — for example `build.sbt:175` sets it with the comment that `MockTexeraDB` swaps a JVM-wide singleton and suites must run serially. A `Tags.limit(Tags.Test, 1)` elsewhere does **not** cover this: as `common/workflow-core/build.sbt` says in the repo's own words, that bounds sbt task concurrency, not ScalaTest's in-JVM distributor. So nothing in amber's build prevents a concurrent suite losing its connection mid-test. The second point is arguably a build-configuration gap worth fixing on its own; it is not specific to this file, but this file is the first amber spec to boot a production `run()`. Remaining after this work: `createAmberRuntime`, `main`, and the `CLEANUP_ALL_EXECUTION_RESULTS` branch, all of which need a started runtime. ### Task Type - [ ] Refactor / Cleanup - [ ] DevOps / Deployment / CI - [x] Testing / QA - [ ] Documentation - [ ] Performance - [ ] Other -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
