It is unclear how to retrieve the Photo ID of a photo after uploading it through the v2 API

[flan]

I am writing a script to migrate some images from another system to Lychee and I have been successful in using the /api/v2/Photo endpoint to upload files to a specific album, and what I get back is, as documented, {'file_name': '[omitted]', 'extension': '.png', 'uuid_name': 'cc4uexJLtXD2nJam.png', 'stage': 'done', 'chunk_number': 1, 'total_chunks': 1}

But what I want to do next is apply descriptions and tags to this image, such as through /api/v2/Photo::tags, and these require a Photo ID. Initially, I assumed this would be uuid_name because it appears to be the only ID-like identifier assigned as part of the upload, but I was met with the response "photo_ids.0 must be a string in Base64-encoding with 24 characters".

Looking at the web UI, I can see that the URL for the uploaded image has a string in this format and it is nothing like the uuid_name value, which is 16 characters (seemingly Base64) plus an extension.

I have tried /api/v2/Map with the intent of searching for uuid_name in the list of photos, since I don't need this to be fast, just reliable, but the photo array I see is empty when using the same Album ID as when uploading.

It is entirely possible that there is an intended way to get the Photo ID after it has been uploaded, and maybe it can't be known immediately because it needs to be processed or checked for duplicates or something asynchronously, but whatever the path to getting the Photo ID is, I am afraid that I cannot find it.

If someone could provide directions, I'd be willing to try to add hints to the API documentation to make it clearer for the next person; this seems like a fairly common use-case.

[ildyria]

Looking at the web UI, I can see that the URL for the uploaded image has a string in this format and it is nothing like the uuid_name value, which is 16 characters (seemingly Base64) plus an extension.

That uuid_name is randomly generated for merging the chunk files. It is not used for Id later.
At the moment there is no "easy" way to get the id and I do agree this is something that is needed.

Even for testing, the way I had to resolve it so far was by: uploading to the root folder (assumption that unsorted is empty) and then querying the content:

$response = $this->actingAs($this->admin)->upload('Photo', filename: $filename);
$this->assertCreated($response);
$this->clearCachedSmartAlbums();
$response = $this->getJsonWithData('Album', ['album_id' => 'unsorted']);
$this->assertOk($response);

return $response->json('resource.photos.0');

The code to process the photo can be found here:
https://github.com/LycheeOrg/Lychee/blob/master/app/Http/Controllers/Gallery/PhotoController.php#L80

Which subsequently creates a ProcessImageJob :
https://github.com/LycheeOrg/Lychee/blob/master/app/Jobs/ProcessImageJob.php#L101

ProcessImageJobs uses Create:
https://github.com/LycheeOrg/Lychee/blob/master/app/Actions/Photo/Create.php#L67

It passes through pipes and ends up with :
https://github.com/LycheeOrg/Lychee/blob/master/app/Actions/Photo/Pipes/Shared/Save.php#L21
->save() preserve the photo in the database creating its new id if not existing with the following method:
https://github.com/LycheeOrg/Lychee/blob/master/app/Models/Extensions/HasRandomIDAndLegacyTimeBasedID.php#L151

[ildyria]

While returning the id at the meta step is possible, it is not guaranteed to be the exact one:

• if there is a duplicate, the id returned will be wrong: the image won't be created.
• if there is a collision, there is no detection done before ->save()

And finally the photo is created only after being processed. So this information is only interesting if you use async job.
It can be made possible, but need to be explored a bit more in details of the how to make it.

[flan]

I should be able to use the empty Unsorted approach for this. That hadn't occurred to me and it seems like a good-enough workaround.

The async pipeline problem is what I suspected, but there might be a simple way to deal with that: report the on-upload ID as provisional_id so it's obvious to someone who only has an example that the ID is unstable, but that it is the field they want. (I'm my case, I wouldn't even need to check because I know my data is pre-filtered, and I suspect a lot of people looking to do automated imports from cameras and other workflows can make the same claim)

Then, with another query, let them poll to see where in the process it is. I presume stage done means it has passed all checks and the Photo ID can now be trusted, which might make it possible for this to be a one-shot in many cases. (But I could be wrong, and that wouldn't change this approach)

In the event of a duplicate or another problem, keeping notes probably wouldn't occupy too much storage, so maybe the result could live in cache until flushed, so that new check endpoint could provide enough context for full automation, and yet another endpoint could acknowledge and clear the record.