CLI sync in - assets in folders are updated on every sync and image URLs return 404

I have…

  • Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.

I’m submitting a…

  • Regression (a behavior that stopped working in a new release)
  • Bug report
  • Performance issue
  • Documentation issue or request

Current behavior

When using sq sync in to sync an app, any asset that has a folderPath is treated as an update on every sync, even when the file content (fileHash) has not changed. Assets at the root sync correctly and are not re-uploaded unnecessarily.

The first sync creates the assets correctly and image URLs are accessible. After the second sync, the version number of folder assets increments and the image URL returns a 404 meaning the asset record exists with correct metadata but the file is not accessible. Every subsequent sync continues to increment the version and the images remain broken.

Expected behavior

Assets with an unchanged fileHash should not be updated on subsequent syncs. Image URLs for folder assets should remain accessible after every sync.

Minimal reproduction of the problem

  • Run sq sync in ./folder --app my-app
  • Check assets in folders - images are accessible after first sync
  • Run the same command again without any changes
  • Check assets in folders - version has incremented and image URLs now return 404

Environment

  • Self hosted with docker
  • Self hosted with IIS
  • Self hosted with other version
  • Cloud version

Version: [VERSION]

Browser:

  • Chrome (desktop)
  • Chrome (Android)
  • Chrome (iOS)
  • Firefox
  • Safari (desktop)
  • Safari (iOS)
  • IE
  • Edge

Others:

This is weird. I would understand that the file is updated unncessarily, but why should it become unvavailable?

Yeah, It doesn’t matter if you use try to pull the new version, old version, or remove the version from the query string. It is always a 404.

I cannot verify it yet.