Uploading a password-protected .xlsb workbook without its password
answered 500 with the unattributable-failure message instead of 400 with
the remedy.
DetectPasswordProtection in pkg/modules/libreoffice/api/protection.go
infers encryption from a compound-file header carried by an extension
whose unencrypted form is always a ZIP package. The ooxmlExtensions map
listed .xlsx, .xlsm, .xltx and .xltm but not .xlsb, so an encrypted
workbook under that extension fell through to PasswordProtectionUnknown.
The convert route in pkg/modules/libreoffice/routes.go then matched
neither password branch of its exit-code switch and returned the 500
default.
An Excel Binary Workbook is an Open Packaging Conventions ZIP holding
binary parts, so a compound file under that extension is encrypted for
the same reason .xlsx is. Adding .xlsb to the map restores the 400 that
names the 'password' form field.
Applies what go fix now proposes, so make fmt is a no-op on a clean tree
instead of dirtying these two files on every run. Both rewrites are
equivalent: Cut's first result matches SplitN(s, sep, 2)[0], and SplitSeq
iterates the same substrings without building the intermediate slice.
restart() reset reqCounter only after a successful Launch, so a failed
one left it at the limit. maybeRestartAfterTask then re-fired on every
subsequent task, producing back-to-back restarts and, with planned
restarts now reporting healthy, a node that keeps restarting while
claiming health.
Reset on the attempt instead. A process that will not start is recovered
by ensureHealthy, which restarts synchronously and reports the failure.
maybeRestartAfterTask ran its restart on a bare background context while
the drain loop in doRestartLocked selects only on ctx.Done(). A task that
never completed blocked the drain forever, pinning isRestarting. Since a
planned restart now reports healthy, that left the node claiming health
for good. LibreOffice escaped it because its concurrency of 1 drains no
slots, but Chromium defaults to 6.
Give that restart its own deadline. On expiry it aborts and the next task
retries it.
The eager restart fired after --chromium-restart-after or
--libreoffice-restart-after conversions made Healthy() report false,
so a client probing /health between two conversions got a 503 from an
otherwise serving node. Tasks arriving during that window are requeued
by acquireSlot, not rejected.
Track whether the in-flight restart is planned and keep reporting
healthy for those. Unplanned restarts still report unhealthy so load
balancers get honest information.
Closes#1648