App-version import creates a separate Function despite unchanged Function ID and configuration

Developer
1

Hello and good evening!

Importing an edited development version of an app created a separate Function and redirected the app’s calls to that duplicate’s snapshot. I’d like to understand why the existing Function wasn’t reused and how to prevent this during future imports.

We verified that the archive edits did not change the Function or its references:

  • All three Function-related JSON files—the FunctionVersionSet and both FunctionVersion files—are byte-for-byte identical, with matching SHA-256 hashes, between the original export and the edited import package.

  • The Function ID and version identifiers were preserved.

  • All three triggers calling the Function are also byte-for-byte identical.

  • The Function entries in the archive’s dependency-reference metadata are unchanged.

Observed result after import:

  • Original Function ID: f10127cf-ab34-40a0-9b30-9678662219cd

  • Imported Function ID: a4cbd752-80b0-4f9d-82fd-ff1edec25ef6

  • A separate Function appeared with “1” appended to its name.

  • All three app calls now reference a snapshot belonging to that separate Function.

  • Comparing subsequent exports confirms that the original and duplicate have identical logic, inputs, outputs, and variables.

Both app exports identify the same source instance, and the app itself retains its original identity. This was an app development-version import, not a standalone Function import.

Your Functions import/export documentation says that an app import should add a snapshot to the existing Function when its ID already exists. The unexpected behavior here is the new Function identity, not the snapshot reference itself.

The instance currently runs r390, deployed October 24. The original export identifies r389, and the duplicate’s creation timestamp is October 21, so the duplication predates that upgrade.

Could you investigate why the importer did not reuse the existing Function ID? Please also confirm the supported workflow for reimporting app changes while retaining references to our centrally maintained Functions. We are experimenting with using AI to assist in development, and import is a key step in that pipeline.

If you require copies of any of the files we compared, I can send them to a member of your team on request.

Thanks,
Evan

2

This is the Reuse aggregation and queries topic all over again. I completely agree that system should not just create duplications of same configuration item if it already exists.

3

Hi @enewton,

Thanks for the detailed write-up. The hashes and IDs made this easy to trace.

Our Functions import/export article is misleading on this point, and I’m getting it corrected. Under the hood, import remaps IDs deterministically, and that remapping also happens when you import back to the site the export came from. So the imported Function gets a new ID and is treated as a new Function, even when the files are byte-for-byte identical. That’s where the “1” copy came from.

To your other questions:

  • Will this keep happening? For your flow, yes. Exporting the exact same Function again gives the same result, but once the app points at the “1” copy, exporting and re-importing creates a “2” copy, and so on. Each round trip creates a new Function.
  • Is there a supported way to re-import app changes and keep pointing at your central Functions? Not today.
  • Cleaning up the copy you have: you can re-point the three calls back to the original Function and archive the “1” copy. Archiving won’t break anything. Just keep in mind the next import will create a new copy again.

Since you mentioned using AI in the pipeline: editing export archives directly isn’t a supported workflow, so it may not keep working as import/export changes. I’d be careful about building too much on top of it, and I’m happy to talk through what you’re trying to automate.

Sorry this cost you time, and thanks again for the thorough report.

Aidan