[netomi]

What

Fixes the crash reported after merging #2089:

WARN --- [backgroundjob-worker] o.jobrunr.server.BackgroundJobPerformer  : Job(..., jobName='Determine file size for published file resource') processing failed
software.amazon.awssdk.services.s3.model.NoSuchKeyException: (Service: S3, Status Code: 404, ...)

FileResourceSizeJobRequestHandler (the size backfill job from #1777/#2089) crashes whenever a FileResource row points at an object that's no longer actually in storage. This isn't transient — retrying will always fail the same way — but the job let it propagate as a generic failure, so it burned through @Retryable's 3 attempts + JobRunr's own 3 retries, then permanently failed and left the migration_item row behind for investigation (per #2092's MigrationItemCleanupFilter), even though there's nothing to investigate: the file is just gone.

This is a known, already-tolerated category of problem in this codebase — see FixMissingFilesJobRequestHandler, which exists specifically to detect and repair extensions with missing files. This PR makes the size backfill tolerate it the same way instead of crash-looping on it.

How

• New FileNotFoundInStorageException (an IOException) signals "the object is confirmed absent", as opposed to some other, possibly-transient, storage error.
• Each storage backend translates its own "definitely not found" signal into it:
  • AWS: a HEAD response has no body, so S3 can't return a specific error code the way a GET can — some SDKs/implementations throw NoSuchKeyException regardless, but a plain S3Exception with a 404 status is what's actually guaranteed. I verified against a real LocalStack S3 instance that LocalStack's HeadObject on a missing key throws the plain S3Exception, not NoSuchKeyException — so the fix checks the status code rather than the exception subtype (matching the pattern this codebase already uses in AzureBlobStorageService.removeFile).
  • Azure: BlobErrorCode.BLOB_NOT_FOUND.
  • GCS: already represented as a null Blob — now translated explicitly instead of a generic IOException.
  • Local: NoSuchFileException from Files.size(...).
  • Any other storage error (auth failure, network blip, throttling, etc.) still propagates unchanged and is still retried as before.
• MigrationService.getFileSize excludes FileNotFoundInStorageException from its @Retryable — retrying a confirmed absence just spends 3 more round trips (and delay) confirming the same thing again.
• FileResourceSizeJobRequestHandler catches it, logs a warning, and leaves the resource's size unset instead of letting the job fail. There's nothing more this job can do for a resource whose file is gone; FixMissingFilesMigration is the actual repair mechanism.

Testing

• New FileResourceSizeJobRequestHandlerTest: the job completes normally (no size set, no exception) when storage reports the object missing; still records the size on the normal path.
• New AwsStorageServiceIntegrationTest.testGetFileSizeThrowsFileNotFoundInStorageExceptionForAMissingObject, run against real LocalStack — this is what caught that LocalStack throws a plain S3Exception, not NoSuchKeyException, for a missing HEAD target.
• Full unitTests suite passes (948 tests) and s3IntegrationTests passes (24 tests).

🤖 Generated with Claude Code