fix(apps): a missing container must not crash FluxOS, a failed redeploy must not uninstall the app, and a log poll must lose nothing

[Cabecinha84]

Status: not ready to merge — a full harness gate has not been run. The unit suite is green (6133 passing, 18 pending, 0 failing) and lint is clean, but the log-polling internals moved substantially after harness suites 58 and 59 last ran, and this branch has never had the whole suite set run against it. That gate is the next thing to happen.

Two failures observed on a live node, three hours apart, both reached from the same line of code. Fixing them opened five more in the same paths, and one of those turned the log endpoint itself into a piece of work: it answered every poll on a 1500 ms timer, lost lines written between polls, and made docker re-read the whole log to do it.

This is the node side of a four-repo change. It is additive — a client that knows nothing about it gets the old behaviour exactly — and it must ship first. See Deployment order.

---

1. FluxOS restart-looped until a browser tab was closed

GET /apps/applogpolling/<component>/100 for an app whose container no longer exists killed the FluxOS process. systemd restarted it, the page polled again, and it died again — one exit per poll.

21:34:45  "OPTIONS /apps/applogpolling/rustoxide_<app>/100"  204
21:34:46  "GET     /apps/applogpolling/rustoxide_<app>/100"  304
21:34:47  fluxos.service: Main process exited, code=exited, status=1/FAILURE

dockerContainerLogsPolling rejected, and appInspector called it from inside a new Promise executor without awaiting the promise it returns — so the rejection had nothing attached to it. The route is privileged (appownerabove), but any app owner could take down every node hosting their app by leaving the log page open across a removal.

The fix is now structural rather than a guard: section 7 rewrote that function to be a plain async function that returns its lines or throws, called from a try/catch. No callback, no second reporting channel, no un-awaited promise left to go unhandled.

2. A live app was uninstalled by a soft redeploy that never removed it

Changing one environment variable on a running app removed it from the node and broadcast the removal:

19:23:41  masterSlaveApps: starting docker component:rustoxide_<app>
19:23:43  REMOVAL REASON: Soft redeploy failure - failed during soft redeploy:
          Cannot read properties of undefined (reading 'Id') (softRedeploy)
19:23:46  {"type":"fluxappremoved", ...}

The catch treated every error as proof the app had been left half-removed. The reconciler had asked to start the same component two seconds earlier, the removal path found no container, and a healthy application was lost to the race. Cleanup is now gated on having actually taken the app down.

3. The shared root: a deliberate TypeError

const myContainer = await getDockerContainerOnly(idOrName);
// Don't throw error here, let it fail with property access error
// to match test expectations
const dockerContainer = docker.getContainer(myContainer.Id);

A container that is not there is an expected outcome. It now throws Container <name> not found.

4. A component redeploy uninstalled the app, every time

Both paths passed null where the teardown expects the component's docker id, and the already-joined component_app where the callee expects the bare app name.

The joined name made the monitoring key frontend_frontend_myapp. The null took each path to a different destruction: soft threw on null.startsWith and the catch uninstalled the whole app, forced and broadcast; hard put the null into sudo umount /mnt/appdata/flux-apps/null, so the volume stayed mounted, mke2fs failed, and the failure path uninstalled both components — broadcasting nothing, so peers went on believing the instance was there.

softUninstallComposedApp is the reference for both arguments. reinstallOldApplications had the same doubled name and was also fixed — that is the automatic path, the one that runs on every on-chain component spec change with no operator involved.

Both paths now publish app:componentRedeployed — { name, component, identifier, hard } — on success only.

5. The endpoint owned no response, and one exit killed the node

With the redeploy fixed, redeployComponentAPI reached a line it had never reached before and answered twice. Fixing that exposed the real defect: the response had no owner. The endpoint opened it and handed the raw res down through four layers, any of which could write and some of which closed it.

A write to a closed response does not throw where it can be caught. Node reports it a tick later as an error event on res, nothing listens, and an unheard error reaches apiServer.js:232's uncaughtException handler, whose answer to anything but a DNS error is process.exit(1).

One rule now: the handler that opened the response is the only thing that closes it, in a finally. Success, failure and refusal reach the same close.

That rule was applied to softRegisterAppLocally first and missed registerAppLocally, which is the hard path — six close sites, plus a teardown passing endResponse: true, so a failed hard redeploy ended on the teardown's "was successfuly removed" while the app was destroyed. Three more of those sites were in softRedeploy's and hardRedeploy's catches. A grep for the pattern across ZelBack/src now returns nothing, and installAppLocally and testAppInstall close their own responses.

And a redeploy that gives up on purpose now says so. When the removal fails part way, the right answer is to leave the app alone for the reconciler — but returning quietly closed the stream on a progress line and answered 200, so a redeploy that never happened read as one that did.

6. "I refused" and "I destroyed the app" were the same value

registerAppLocally answered false both for "another operation holds the node, I touched nothing" and for "I failed and have already torn the app down". The redeploy paths read it as the second.

So: a component redeploy tears the component down; the spawner starts an unrelated install inside composedDelay — nothing in appSpawner consults any in-progress flag; the reinstall is refused; and the redeploy answers a five-second scheduling collision by force-uninstalling a healthy app and broadcasting it. Section 2's shape, reintroduced by the change meant to stop it reporting false success.

InstallOutcome is a frozen enum in the shape of Privilege, and its docblock says what Privilege's cannot: nothing answers these to a client, so the values are ours as well as the names.

INSTALLED  // it worked
REFUSED    // nothing touched — the app is exactly as it was
FAILED     // it got part way and tore down — the app is gone

All eleven call sites moved with the return type rather than being left to be found later: every value is truthy, so a site left on if (!outcome) reads a refusal as a success. The spawner no longer matches on error text to work out which case it is in — its own comment had been complaining about exactly that.

7. The log endpoint answered on a timer, lost lines, and re-read the whole log

Cost. follow: true never closes, so the only way out was a 1500 ms timer — every poll took 1500 ms whether one line was waiting or none. Measured: 1526, 1507, 1507 ms, each returning a single line.

Loss. It asked for the last N lines and the reader replaced its view with them, so anything beyond N between two polls was never shown. since did not help: it was a box a user typed into, it never advanced, and docker applies tail after since.

A reader is now given an opaque position and hands it back. Docker's since is inclusive and millisecond-resolved, so the line asked from always comes back — which is the proof there is no gap, and why a position must never advance past a line already held.

Three things the first version of this got wrong, all found by adversarial review and fixed here:

The log is not in timestamp order. A container writing to stdout and stderr has two writers, each stamping its line before the write is serialised — 3,304 backwards steps in 40,000 lines, measured. Counting the overlap by millisecond therefore missed already-delivered lines stamped just before it, and the tail of each page was delivered twice: 19 and 57 duplicates over two walks of a real log, 0 missing in both. count is now a place in the sequence docker returns, and ms is the newest timestamp delivered rather than the last line's. Walked end to end against a container alternating both streams: 12,000 lines, 0 duplicates, 0 missing, at two page sizes.

since alone re-reads the whole log. There is no index to seek with. 74 ms at 3.5 MB, 273 ms at 14 MB — and section 9's retention floor guarantees the log is always full, so that was the steady state for every open viewer. With tail present docker opens at the end and answers byte-for-byte the same in ~4 ms, flat. A positioned read sends tail = maxLines + 1; the extra frame says whether the whole set fitted, and only a reader more than a page behind pays for the scan, once. Steady-state poll: 14–15 ms against both a 3.5 MB and a 14 MB log.

A since filter is not a position, and all is not a page. A typed date was turned into a position, which dropped its line count and answered rolledOver — a data-loss warning — because a hand-typed timestamp does not land on a log line. And the 5000-line cap applied to all, keeping the oldest of them, so a caller asking for every line got the start of the log. Both are restored to what they were; see Backwards compatibility.

8. Finding a container listed every container on the node

getDockerContainerByIdOrName scanned listContainers({all: true}) to turn a name into an id. It has sixteen call sites — start, stop, restart, remove, inspect, exec, stats, logs.

Docker filters server-side, so one record comes back whatever the node is running. The exact name comparison stays and is load-bearing: the filter is a regex match, so web matches fluxwebsite too. Verified against a real daemon — websitelong resolves to itself, and websit is refused although the filter returns fluxwebsite for it.

9. An app's logs keep a floor of history instead of none

Every app container was created with one 20 MB log file. Docker does not trim a full log file, it discards it — so readable history swung between 20 MB and nothing. Measured: 400 lines into a 4 KB budget kept 20 lines at max-file: 1 and 107 at max-file: 4.

Four 5 MB files is the same 20 MB of disk and only the oldest quarter is dropped per rotation, so at least 15 MB is always readable.

This matters to section 7: a position can only be honoured if the line it names still exists. With one file, no position was ever safe. With four, any position within the last 15 MB is guaranteed present, and a genuinely lost one is reported as rolledOver rather than becoming a silent gap.

The setting is fixed at container creation, so it reaches an app when it is next redeployed. Nothing needs tearing down.

10. Deleted: a log endpoint no route could reach

appLogStream has never been routed, on any branch — git log -S over routes.js finds no route that ever named it. It traces to 766cff709, 2021-02-10, the ZelFlux rename, and was called by nothing for four and a half years.

It looked alive — its own privilege check, a content type, a place on the export list, a describe block — which is why two commits here carried fixes for code nothing could execute. It was also still broken one line below where those fixes landed: appInspector passed the error object to res.write, which takes only a string or Buffer.

Its only consumer, dockerContainerLogsStream, goes with it.

---

Testing

Unit — 6133 passing, 18 pending, 0 failing

Lint clean on every changed file.

Every behavioural fix was proved red by mutating the exact logic it names, then restoring the file byte-identical — dropping the overlap skip, suppressing the rollover flag, taking the position from the newest line instead of the last delivered, sending tail alongside a position, removing the bound from a positioned read, trusting docker's filter without the exact comparison, treating a since filter as a position, capping a caller with no position, re-adding a res.end() in the installer, making the left-alone path silent, and recording a raw-id removal.

Test doubles that were wrong, and are now faithful. This kept happening, so it is worth stating: the streaming res double accepted a write after close; removeAppLocally was stubbed to resolve without closing the response; registerAppLocally was stubbed to resolve undefined when it answers a value; twelve res doubles in appInstaller.test.js had no end; and the log fixtures were built in timestamp order, encoding the assumption they existed to check.

Two tests that could not fail. should return false if app already installed never reached the guard it named — the guard and the catch both answered false, so it passed on the catch. And a test of mine asserting the silent path reports drove a throw, which reaches the catch, which always wrote. Both re-pointed; the second proved red afterwards.

Integration

Suite 58 (58-component-redeploy-keeps-the-app.js) and suite 59 (59-app-log-polling-loses-nothing.js) both passed on a real fleet at the point they last ran, and 59 was proved red 4/4 against the pre-change code. Both predate the section 7 rework and need re-running — see the status note at the top.

Suite 59 asserts every line is seen exactly once across ten polls, that five consecutive polls each answer in under a second, and now that a since filter honours its line count and all is not truncated. Its writer alternates stdout and stderr, because a stdout-only writer cannot produce the out-of-order case.

End to end on a live node

Deployed to a real Arcane node and driven through the FluxOS frontend, with an app registered for the purpose writing a numbered line every second.

204 lines rendered, range 291–494, contiguous, 0 duplicates, 0 gaps. It appends — 180 → 192 → 204 while the first line stayed pinned at 291 — and 204 is past the 100-line limit, which the replace behaviour could never produce. The cursor was visible on the wire.

Log retention, A/B on one node, same FluxOS, the only variable being when the container was created:

container	created	log config
an app installed before this change	2026-08-31	max-file: 1, max-size: 20m — floor of zero
the app installed after it	2026-09-04	max-file: 4, max-size: 5m — floor of 15 MB

---

Backwards compatibility

A request without a cursor behaves exactly as it did before, and that is now true of all three shapes a deployed client sends:

request	before	now
/applogpolling/app/100	last 100 lines	last 100 lines
/applogpolling/app/all	every line	every line
/applogpolling/app/100/<date>	last 100 after that date	last 100 after that date
/applogpolling/app/100?cursor=…	—	the next batch

A client that knows about positions gets no cursor field back from an older node and falls back per node, per request — there is no version check anywhere, because the presence of the field is the capability signal. The cursor is a query parameter rather than a path segment for the same reason: the route has three optional segments and a fourth would 404 on a node that predates this.

Deployment order

1. This PR, once the gate is green. Additive in both directions, and useful on its own — the 1500 ms fix, the container-lookup fix and the retention floor reach every existing client with no frontend change.
2. The three viewers, in any order and independently:
   • feat(logs): read from where the viewer got to, so no log line is missed fluxos-frontend#155 — LogViewer.vue
   • feat(terminal): read from where the panel got to, so no log line is missed palworld-server-website#40 — ServerTerminal.jsx
   • RunOnFlux/minecraft-server-website#24 — ServerTerminal.jsx

The reverse order is harmless but pointless: a viewer shipped first would send a cursor every node ignores and sit in the fallback path.

Two line-ending PRs are stacked behind the viewer changes and are not part of this work: RunOnFlux/minecraft-server-website#25 and RunOnFlux/palworld-server-website#41.

Note on authorship

The first four commits are Valter Silva's, rebased onto current development with authorship intact. Sections 7 and 10 supersede parts of that work: the log-poll rewrite replaces the callback contract two of those commits established, and the deleted appLogStream is the code a third was fixing. That is not a criticism — they were correct for the code as it stood, and establishing that the endpoint was unreachable took a git log -S across every branch.

🤖 Generated with Claude Code

[MorningLightMountain713]

Reviewed the diff against development (4c3e1a848...f40ae6e9b). Both fixes address real failures and the crash fix works — I reproduced the polling crash on development and confirmed it does not occur on this branch. Four things to change before it lands.

1. The "left intact" message is not true in the case that produced the incident

softRemoved (advancedWorkflows.js:1262) is set after softRemoveAppLocally returns, so false means "the removal did not finish", not "the removal did not start". The catch at :1361 then logs the installation is left intact.

softRemoveAppLocally is a sequence: guards, spec lookup, decrypt, softUninstall*, cleanupAppDatabase. The uninstall step itself stops monitoring, then calls appDockerStop (errors swallowed by its .catch), then appDockerRemove (appUninstaller.js:651, not caught). The failure in the description throws at that last call — after monitoring has already been stopped.

For a composed app it is more than wording. softUninstallComposedApp (:1113) removes components one at a time. On this branch, with a two-component app whose second removal fails:

appDockerRemove -> fluxb_TestApp    removed
appDockerRemove -> fluxa_TestApp    Container fluxa_TestApp not found
removeAppLocally                    not called          <- the new gate, working
log.warn  "Soft redeploy of TestApp failed before the app was removed
           - the installation is left intact"

One component's container is gone and the journal says nothing happened. Either set the flag before the destructive step so it means what it says, or have the message state what is actually known: the redeploy failed during removal, no forced uninstall, convergence left to the reconciler.

2. softRedeployComponent has the same defect, and it fires on every call

advancedWorkflows.js:1515 passes appId as literal null:

await appUninstaller.softUninstallComponent(fullComponentName, null, componentSpec, res, stopAppMonitoring);

appDockerStop(null) is absorbed by its .catch; appDockerRemove(null) is not. It reaches getAppIdentifier(null) → null.startsWith, which throws upstream of the new if (!myContainer) guard at dockerService.js:208, so this PR does not change it. On this branch, redeploying a component that does exist in the spec:

REMOVAL REASON: Soft redeploy failure - myapp being removed after component
frontend_myapp failed during soft redeploy:
Cannot read properties of null (reading 'startsWith') (softRedeployComponent)

removeAppLocally("myapp", <res>, force=true, endResponse=true, sendMessage=true)

Chain: getAppIdentifier (dockerService.js:49) ← getDockerContainerOnly (:187) ← appDockerRemove (:1303) ← softUninstallComponent (appUninstaller.js:651) ← softRedeployComponent (advancedWorkflows.js:1516).

Passing the component's real appId fixes it. hardRedeployComponent passes null the same way at :1631 but survives it, because hardUninstallComponent tolerates the failed removal and continues — so only the soft path changes behaviour, though the argument is wrong in both.

3. The polling fix belongs at the call site

The defect is at appInspector.js:175: an async function called inside a new Promise executor, its returned promise neither awaited nor caught. Reproducing that shape against a missing container on development produces the unhandled rejections; on this branch it produces none, so the fix does work. But it works by making dockerContainerLogsPolling resolve after it failed, which leaves the function's promise reporting success on failure and only covers throws inside the current try.

dockerService.dockerContainerLogsPolling(appname, parsedLineCount, since, cb).catch(reject);

at the call site keeps the promise honest and covers every path through the function.

Two related points in the same area:

• A single docker error now reaches the callback twice. dockerService.js:469 calls callback(err) and then rejects into the outer catch, which calls callback(error) again. With the rethrow removed the callback is the only reporting channel, so the duplicate is now the visible behaviour.
• dockerContainerLogsStream, which this PR also edits, has a second throw at dockerService.js:385 sitting inside the dockerContainer.logs callback rather than the enclosing try, so the function's own catch does not cover it. Worth folding into the same handling while the file is open.

4. Test coverage of the new branch

advancedWorkflows.test.js:3866 stubs the spec lookup to return null, so the throw is Flux App not found at advancedWorkflows.js:1226 — before any docker call is made. The failure in the description comes from appDockerRemove in the middle of the removal, and that is the case worth pinning. The other half of the new gate — a failure after the app is down still running the cleanup — is worth an assertion too; the only removeAppLocally expectation added is .called === false.

Smaller things

• appReconciler.test.js:614, 625, 640, 661, 824 build new TypeError("Cannot read properties of undefined (reading 'Id')") under a comment describing it as the "production shape of a genuinely-missing container". After this change the shape is Container <name> not found; the fixtures should follow even though the handling is message-agnostic.
• getDockerContainerOnly already logs Container ${idOrName} not found at dockerService.js:189, and the caller now throws the same string, so each miss is reported twice with identical text. The log line is redundant now that the condition is an error.
• dockerTerminalHandler.js:64 and test-infra/runner/tests/53-terminal-exec-crash-safety.js:25 both document the .Id-off-undefined mechanism this PR removes. Both still behave correctly, but the comments now describe something that no longer exists.
• The new describe at advancedWorkflows.test.js:3845 is inserted into the middle of a four-line comment, leaving // that require extensive mocking of database connections... orphaned after the block.

Stacking

No conflict with #1781, #1784 or #1791. #1784 already conflicts with the development tip in advancedWorkflows.js and five other files; merging this branch in produces the same six and no more. #1781 and #1791 merge clean both with and without it.

[Cabecinha84]

All four addressed in 77aa571, plus a second defect at the same call site.

2. softRedeployComponent — the appId, and the app name too

Fixed in both component redeploys, and the argument was wrong twice, not once.

softUninstallComponent(appName, appId, ...) uses appName to build ${componentName}_${appName} for the monitoring key and hands it to cleanupPorts. Both call sites passed the already-joined fullComponentName, so a component redeploy of frontend_myapp stopped monitoring for frontend_frontend_myapp — a key that does not exist — and left the real monitor sampling a container that was about to be removed. softUninstallComposedApp (:1114) is the reference: bare app name, docker id of the component. Both paths now match it.

So GET /apps/redeploycomponent/:app/:component without force was a one-call app-wide forced uninstall, on every call.

3. The polling fix

.catch(reject) added at appInspector.js:189, and the return in the catch kept — the two cover different things and I would rather have both.

Duplicate callback removed: the three inner sites (if (err), mystream.on('error'), the stream-processing catch) now only reject. The rejection is awaited and lands in the function's catch, which is the single place that reports. The catch case was also reporting a rewritten message (An error occurred while processing the log stream) while rejecting with the original; the caller now gets the original.

dockerContainerLogsStream:385 — folded in, and it is worse than a stale comment. That throw is inside dockerode's callback, so the enclosing try has long returned when it fires. There is no uncaughtException handler anywhere in the repo (nor unhandledRejection — which is why the polling crash was fatal in the first place), so it is the same process kill by a different route. It reports through the callback now.

1. The message

Gate unchanged, wording is now what is actually known:

Soft redeploy of <app> failed during removal: <error>. No forced uninstall -
the app is not known to be down, and convergence is left to the reconciler.

I kept the flag where it is rather than moving it before the destructive step. Setting it earlier would restore the original incident: the failure there came from inside the removal, racing the reconciler, and that is exactly the case that must not uninstall. The comment on the declaration now says outright that false means "did not finish", not "did not start".

4. Tests

Three now, replacing the one:

• failure part way through the removal — a v3 spec so the removal takes the simple path, softUninstallApplication rejecting with Container fluxTestApp not found. Asserts the stub was actually called, so it cannot silently regress to failing early again. This is the incident's shape.
• failure before the removal starts — the previous test, kept as the other end of the range.
• failure after the app is down — checkAppRequirements rejecting once the removal has completed; asserts removeAppLocally IS called, with ('TestApp', null, true, true, true). That was the untested half of the gate.

Smaller things

• appReconciler.test.js fixtures now throw Container www_App not found, with the comment corrected.
• The redundant log.error in getDockerContainerOnly is gone. Both direct callers (appInspector.js:606, appReconciler.js:459) treat a miss as an answer to a question they asked and log their own line, so it was noise on a healthy node; getDockerContainerByIdOrName, whose contract is that the container exists, still throws that text.
• dockerTerminalHandler.js:64 and test-infra/.../53-terminal-exec-crash-safety.js:25 comments updated to the new mechanism.
• Orphaned comment at advancedWorkflows.test.js reassembled — the new describe now sits after it.

Full unit suite: 5657 passing, 5 pending, 0 failing. eslint clean on every file touched.

[codecov]

Codecov Report

❌ Patch coverage is 81.15183% with 36 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.69%. Comparing base (cba4798) to head (12e382d).
⚠️ Report is 136 commits behind head on development.

Files with missing lines	Patch %	Lines
...ack/src/services/appLifecycle/advancedWorkflows.js	68.35%	25 Missing ⚠️
ZelBack/src/services/appLifecycle/appInstaller.js	80.95%	4 Missing ⚠️
ZelBack/src/services/dockerService.js	93.65%	4 Missing ⚠️
ZelBack/src/services/appManagement/appInspector.js	40.00%	3 Missing ⚠️

Additional details and impacted files

@@               Coverage Diff               @@
##           development    #1794      +/-   ##
===============================================
+ Coverage        67.77%   68.69%   +0.91%     
===============================================
  Files              188      190       +2     
  Lines            35087    35133      +46     
===============================================
+ Hits             23780    24133     +353     
+ Misses           11307    11000     -307     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Cabecinha84]

Follow-up in eee2139: the logStream.on('error') handler I mentioned in passing turned out to be half of a real leak, so I took the whole polling path rather than just the duplicate report.

follow: true makes dockerd hold a connection open for the life of the container. The 1500ms window ended the local PassThrough and left the source streaming, so the only path that resolved the awaited promise — mystream.on('end') — could not fire on a live container. The function never returned and never released the connection. Once per poll, on an endpoint a browser hits on a timer, which is the same browser tab that produced the crash in the first place.

Verified rather than reasoned: the new test times out at 10s against the previous code and completes in ~1.5s here.

  1) completes the poll and reports the end exactly once:
     Error: Timeout of 10000ms exceeded.        <- development
      ✔ completes the poll and reports the end exactly once (1518ms)   <- here

The logStream.on('error') handler was the other half: it reported through the callback without settling the promise, so an error on that stream produced the same permanent hang plus the duplicate report.

What changed:

• Every terminal condition settles. end is the success — it fires after the last chunk is read, so every line has reached the callback by then. close is the backstop, because a stream that errored may never emit end and an unsettled promise here is a leaked connection. Errors from either stream reject, unless the window is deliberately closing.
• The window destroys the source before ending the sink. demuxStream writes into logStream, and a write landing after end() surfaces as ERR_STREAM_WRITE_AFTER_END — a completed poll reported as a failure.
• A finally destroys the follow stream on every exit.
• Stream ended moved out of the stream handler to after the await, so it is reported once and only on success. From inside the handler it could follow an error the caller had already been handed, telling it the poll had finished cleanly.

Description updated with sections 4 and 5. Full unit suite: 5658 passing, 5 pending, 0 failing.

[Cabecinha84]

@MorningLightMountain713 ready for another look when you have time.

All four points addressed in 77aa571, plus the polling path taken properly in eee2139 after your note on dockerContainerLogsStream led somewhere worse than a stale comment.

Two things worth your eye in particular, since they go beyond what you flagged:

1. softRedeployComponent had a second wrong argument next to the null appId — both component redeploys passed the already-joined component_app where the callee expects the bare app name and rebuilds the join itself, so the monitoring key became frontend_frontend_myapp.
2. dockerContainerLogsPolling never released the docker connection it opened. The logStream.on('error') handler you pointed at was half of it; the other half is that on a live container the awaited promise had no reachable path to settle at all. Confirmed against development rather than argued: the new test times out at 10s there, completes in ~1.5s here.

Full unit suite: 5658 passing, 5 pending, 0 failing.

[Cabecinha84]

Blocking: advancedWorkflows.js:1157 — the teardown outlives the response it writes into

// softRegisterAppLocally, catch block
const appUninstaller = require('./appUninstaller');
appUninstaller.removeAppLocally(appSpecs.name, res, true, false); // <- no await
return InstallOutcome.FAILED;

registerAppLocally (the hard path) awaits its equivalent. This one does not — and it is pre-existing, but the PR makes it
harmful. Before, endResponse defaulted to true, so the floating teardown owned the close and its output reached the
client. Now it is false and the endpoint closes in a finally. Ordering:

1. redeployComponentAPI → softRedeployComponent → softRegisterAppLocally throws (image pull, port conflict, docker error —
   routine).
2. Catch starts removeAppLocally and returns FAILED synchronously. removeAppLocally runs to its first await
   dbHelper.findOneInDatabase(...) (appUninstaller.js:842) and suspends before any of its progress writes.
3. Caller sees !== INSTALLED → writes "not reinstalled (failed)" → returns.
4. redeployComponentAPI's finally → res.end().
5. removeAppLocally resumes → hardUninstallComponent(..., res, ...) → dozens of res.write into a closed response.

I checked whether that is actually fatal on Node 22, because it matters:

destroyed=true, finished=true -> write is a silent no-op
destroyed=false, finished=true, writableFinished=false -> UNCAUGHT: ERR_STREAM_WRITE_AFTER_END, exit 7

The second case is a response whose body is still flushing — a streaming redeploy endpoint to a real browser over a real
network. So section 5's premise is right, and this call re-arms it. Same for redeployAPI → softRedeploy (line 1425). Fix
is one word:

await appUninstaller.removeAppLocally(appSpecs.name, res, true, false);

Secondary effects of the same missing await, worth fixing regardless: the endpoint answers and clears
softRedeployInProgress while a forced uninstall is still in flight.

Why the tests miss it: does not report a component redeploy that never reinstalled the component
(advancedWorkflows.test.js:4480) drives exactly this path, but appUninstaller.removeAppLocally is a sinon stub that
resolves instantly and writes nothing, so res.writesAfterEnd stays empty. That is the same
test-double-is-more-forgiving-than-reality problem the PR body says it went and fixed elsewhere.

---

Non-blocking

1. truncated changed meaning for existing clients. Was logs.length >= lineCount; now it is only ever true for a positioned
   reader. Every deployed viewer without a cursor now gets truncated: false always. The compat table covers logs
   faithfully but not this field.
2. reinstallOldApplications still ignores InstallOutcome at advancedWorkflows.js:4335, 4455, 4562, 4569. On REFUSED
   (spawner holds installationInProgress) the component has been uninstalled and not put back, and the loop then logs
   Composed application … updated and restarts the app. Pre-existing, but this is the automatic path section 4 argues is
   the important one, and the new enum makes it a two-line check.
3. fluxRemovedContainers has no TTL and is not dropped on read. Only a successful appDockerCreate or a full
   removeAppLocally clears an entry. If recreateMissingContainers keeps failing, container_vanished stays suppressed for
   that container for the life of the process. Dropping the entry when the reconciler consults it would close that.
4. Catch-up re-read cost. When a reader is more than a page behind, the unbounded docker logs read pulls the whole
   retained log (up to 20 MB) into a Buffer plus a full line array, once per poll until caught up. Bounded and rare, but
   it is a per-request memory spike on a memory-tight node. A very large tail instead of none would keep the seek-from-end
   property.
5. Same-class defect one function away: appInspector.appExec's callback does res.write(errorResponse) with an object, from
   inside a dockerode callback — a TypeError with no catcher, i.e. the exact defect section 10 describes in the deleted
   appLogStream. And dockerContainerExec does if (err) callback(err) without returning, then dereferences mystream.
   Pre-existing, out of scope, but it is the next one.