Summary

When batch_mode=async is configured, batcher.Commit returns immediately with a nil *api.MediaItem result (the actual commit happens later in a background goroutine). The old code unconditionally passed this nil to o.setMetaData(info), which dereferenced it and panicked:

runtime error: invalid memory address or nil pointer dereference
goroutine ... github.com/rclone/rclone/backend/googlephotos.(*Fs).Put(...)
    backend/googlephotos/googlephotos.go

This made batch_mode=async completely unusable — any Put or Update call would crash rclone.

Root Cause

In lib/batcher/batcher.go:

func (b *Batcher[Item, Result]) Commit(...) (entry Result, err error) {
    ...
    if b.async {
        return entry, nil   // ← returns nil *api.MediaItem
    }
    ...
}

In backend/googlephotos/googlephotos.go (before fix):

info, err = o.fs.batcher.Commit(ctx, o.remote, uploaded)
// ...
o.setMetaData(info)  // ← panics when info == nil

Fix

setMetaData is given an explicit nil guard:

func (o *Object) setMetaData(info *api.MediaItem) {
    if info == nil {
        o.bytes = -1
        return
    }
    // ... fill remaining fields from info
}

The Update call site is also updated to use the local source size as o.bytes when info is nil, so the hasher overlay (PR #9500) can cache the hash under the correct fingerprint without waiting for the batch to flush:

if info == nil {
    o.bytes = src.Size()   // use local size; async batch will resolve later
} else {
    o.setMetaData(info)
}

All three Object constructors (newObjectWithInfo, newObject, Put) are also updated to initialise o.bytes = -1 explicitly, removing a latent assumption that the zero value of int64 (0) represents "unknown".

Effect on Other Backends

The nil guard in setMetaData is defensive programming that has no effect on any backend except Google Photos in async batch mode. The bytes = src.Size() assignment only executes when info == nil, which only happens from batcher.Commit in async mode.

batch_mode=sync (the default and recommended setting) is completely unaffected.

Commit Structure (TDD)

Automated Tests

=== RUN   TestAsyncBatchModePanic
--- PASS: TestAsyncBatchModePanic (0.00s)
ok  github.com/rclone/rclone/backend/googlephotos  0.4s

Manual Test Plan

Prerequisites

go build .

curl -L -o test_photo.jpg  "https://picsum.photos/seed/rclone_pr4_a/800/600"
curl -L -o test_photo2.jpg "https://picsum.photos/seed/rclone_pr4_b/800/600"

Step 1: Upload with async batch mode — must not panic

./rclone copy test_photo.jpg gphotos:album/rclone_PR4_Test \
  --gphotos-batch-mode=async --gphotos-batch-size=1 -v

Before the fix this crashed immediately:

runtime error: invalid memory address or nil pointer dereference

Expected after fix: command completes successfully.

2026/.../INFO  : test_photo.jpg: Copied (new)
Transferred:      1 / 1, 100%

(--gphotos-batch-size=1 flushes the async batch after every item so the commit happens before the process exits, making the file immediately visible.)

Step 2: Verify the file is visible in the album

./rclone lsf gphotos:album/rclone_PR4_Test/

Expected:

test_photo.jpg

Step 3: Overwrite with async batch mode — must not panic

./rclone copyto test_photo2.jpg gphotos:album/rclone_PR4_Test/test_photo.jpg \
  --gphotos-batch-mode=async --gphotos-batch-size=1 --ignore-times -v

Expected: completes without panic.

2026/.../INFO  : test_photo2.jpg: Copied (replaced existing) to: test_photo.jpg
Transferred:      1 / 1, 100%

Step 4: Verify only one file remains

./rclone lsf gphotos:album/rclone_PR4_Test/

Expected (deduplication means the old version is gone from the album; it may still exist in the library or trash album if trash_album_name is configured):

test_photo.jpg

Cleanup

1. Open the Google Photos Web UI, navigate to the rclone_Trash album, select all photos, and click "Move to trash" (or delete them).
2. Purge the empty album containers:

./rclone purge gphotos:album/rclone_PR4_Test
./rclone purge gphotos:album/rclone_Trash

3. Remove local test files:

rm test_photo.jpg test_photo2.jpg

Dependencies (gh-stack)

This PR is part of a stack. It depends on:

• PR googlephotos: implement deletion workaround via trash album (opt-in) #9498 — gphotos-trash-album: trash workaround + error propagation
• PR googlephotos: map EXIF/IPTC/XMP description to Google Photos description field #9499 — gphotos-exif-description: EXIF/XMP description mapping

It does not depend on PR #9500 (fix-equal-hash-modtime-unsupported), which is a standalone hasher fix.