fix: record why an async publish failed, and restore the retry #1529 disabled

[netomi]

Follow-up to #2170, covering the second half of #1450: a version whose publish fails just stays inactive.

Async publishing is a deliberate design decision — storing, signing and checksumming a package are slow and have no business holding the upload request open. The gap is that when that work fails, nothing writes down why.

Nothing recorded the reason

A failed attempt left the row at active = false and that was the whole of it. The only account was Spring's SimpleAsyncUncaughtExceptionHandler line, which names PublishExtensionVersionHandler.publishAsync and not the extension it was working on — so an operator finding an inactive version had to correlate it against a stack trace by hand, which is exactly what the reporter did.

V1_75 adds extension_version.publish_error, set when an attempt fails and cleared when a version is activated, so it always describes the latest attempt rather than accumulating history.

Two deliberate choices in it:

• Type and message only, no cause chain. A chain carries file system paths, host names and connection strings out of the server and into a column that admin tooling reads back, and none of it tells an operator more than the log already has — which is where the stack trace stays.
• Its own transaction (REQUIRES_NEW), because the transaction the failure happened in is on its way to being rolled back and would take the record with it.

The user-facing side of the same gap

UserAPI.enrichWithReviewStatus is driven entirely by scan records. On an instance that does not run scanning — the reporter's setup — scanResult is null, so an inactive version reported "Your extension is being reviewed" indefinitely, for a version nothing was reviewing or ever would.

A recorded failure now outranks every scan state there. rejected is the closest of the three statuses that vocabulary has (the version will not become live without someone intervening) where under_review promises attention nothing is giving it. The recorded reason itself stays out of that response — it names server internals and there is nothing in it a publisher could act on — so they are pointed at the operator, who has the column.

The Error walked past the catch

publishAsync caught Exception in order to call markScanAsErrored. OutOfMemoryError is an Error, so the very failure that prompted #1450 slipped past it — even on an instance running scanning, nothing was recorded. Now it catches Throwable, records the reason, names the version in the log, and marks the scan where there is one.

The retry has not run since #1529

doPublish carries @Retryable, and the comment above its file-resource cleanup — "Delete file resources in case publishAsync is retried" — exists to make an attempt repeatable. Neither has done anything for a while.

Before #1529 the method was:

@Async
@Retryable
public void publishAsync(TempFile extensionFile, ExtensionService extensionService) {

Public, called from ExtensionService through the proxy, so both annotations applied. #1529 extracted the body into a private doPublish and moved @Retryable onto it — a method reached only by self-invocation, where no proxy can ever apply it. Nothing failed; the retry just quietly stopped happening. (@EnableResilientMethods is on RegistryApplication, and the @Retryable on the public createExtensionVersion does still work, which is what makes this easy to miss.)

Moved back onto the public methods, with one deliberate change: includes = Exception.class, so an Error fails on the first attempt instead of being retried three more times into a JVM that has just said it has no room — the exact scenario in #1450. That also matches what was retried before the move: spring-retry's SimpleRetryPolicy defaults to Exception, not Throwable.

Tests

PublishExtensionVersionHandlerRetryTest builds the handler behind real async and retry advice, rather than constructing it directly the way the existing handler test does — the behaviour under test is the advice, so a bare object cannot show it. A synchronous executor makes @Async run inline so nothing has to wait.

• recordsWhyThePublishDidNotFinish — the reason reaches the version.
• recordsTheFailureTypeWhenItCarriesNoMessage — the type alone, not a bare null appended to it.
• retriesAFailedPublish — a storage failure is attempted four times (one plus three retries).
• doesNotRetryAnError — an OutOfMemoryError is attempted once.
• recordsAnErrorAgainstTheScan — the scan is marked errored with the OutOfMemoryError named.

Plus, on the service: the reason is written onto the managed row, a purged row is ignored rather than turning a failed publish into a second failure, and activation clears an earlier failure.

I checked the retry test actually bites rather than trusting a green run: with @Retryable back on the private doPublish, it fails with one attempt instead of four. The migration was applied against a real Postgres 16 to confirm the column lands nullable with no default — which also means import-db-dump.sh correctly treats it as needing no backfill.

Full server suite green (1175 tests), formatter clean.

Not in here

Surfacing the recorded reason through the admin API, so an operator can read it without reaching for psql. The column is the prerequisite; where it gets displayed is a separate decision.

🤖 Generated with Claude Code