Skip to content

URLSession.upload(_:to:) calls async data(for:) without @available guard #327

Description

@leogdion

Finding

Sources/MistKit/Service/Assets/URLSession+AssetUpload.swift:47 defines:

```swift
public func upload(_ data: Data, to url: URL) async throws -> (statusCode: Int?, data: Data) {
let request = URLRequest(forAssetUpload: data, to: url)
let (responseData, response) = try await self.data(for: request)
...
}
```

There is no `@available` annotation on this extension or function, but URLSession.data(for:) (the async overload) requires macOS 12.0+ / iOS 15.0+ / tvOS 15.0+ / watchOS 8.0+. The function's primary callers, CloudKitService+AssetUpload.swift:40 and CloudKitService+AssetOperations.swift:42, are pinned at @available(macOS 11.0, iOS 14.0, tvOS 14.0, watchOS 7.0, *). Package.swift declares deployment targets of .macOS(.v10_15) / .iOS(.v13) / .tvOS(.v13) / .watchOS(.v6).

So the call to data(for:) is unguarded against deployment targets that don't have the API.

Why it matters

Either:

  1. CI is silently skipping the lowest deployment targets (and the build would actually fail there), or
  2. A pre-concurrency Foundation backport happens to make the call compile, but that's brittle and undocumented.

The PR #298 review proposed bumping the asset-upload service surface to macOS 12 / iOS 15 / tvOS 15 / watchOS 8, motivated by adopting async URLSession.upload(for:from:delegate:). Commit `4e968ac` on the PR #322 branch made that bump, but it didn't reach `main` — `CloudKitService+AssetUpload.swift` and `CloudKitService+AssetOperations.swift` still pin macOS 11 / iOS 14.

Suggested fix

Either:

  • Pin the floor: add `@available(macOS 12.0, iOS 15.0, tvOS 15.0, watchOS 8.0, )` to the `URLSession.upload(_:to:)` extension and the two `CloudKitService+Asset` extensions, and bump the corresponding `#available` guards in tests. (This is the v1.0.0-beta.1 review proposal.)
  • Or stop using `data(for:)` on the older targets — e.g., conditionally compile against `URLSession.upload(_:from:)` with completion handler bridging on macOS 11 / iOS 14.

The first option is much simpler and is what the v1.0.0-beta.1 review already proposed.

Found while

Resolving #313 (PR #326). Captured here rather than expanded in scope.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions