Custom Objects Display Id is Not Unique

Hi Everyone,

We are using Custom Objects for our app. As per the documentation, the display_id of a record should be unique and the creation of display_id will be taken care of by the product.

When we created records in custom objects, for all the records we received the same display_id.

For example, a process happens on our app and during the process, the app will create records in Custom Object. In a single process, more than 20 records will be created in less than a minute time.

Why does the display_id not being unique in this case? What we are doing wrong?

Hi @arshath.h,
Thanks for bringing this to our attention.

This is true. Ideally, the display_id is managed by the platform and doesn’t have to be updated by the developer. To clarify:

  • Does it happen during FDK local testing? If so, can you share the fdk debug logs when such a situation occurs?

This is a good observation. Could you please share the app zip via DM so that I can take a closer look?

1 Like


It happened on FDK local testing. I will share the logs soon.

I have shared the app zip in DM.

Hi @arshath.h,
I tried to replicate the scenario by creating the records in a loop within a window of 1 second. As you can see the display_id seems to be duplicate like you mentioned.

I then attempted to wait for every record creation by using asyncawait pattern and it seems to work fine :slight_smile: I would recommend waiting for the creation operation’s competition before the next one begins. This can be achieved with the aforementioned async … await / Promise.all[…] patterns.

I did take a closer look at the timestamps and the underlying code

The FDK tries to simulate the actual custom objects service locally using SQLite. It is likely that it creates a duplicate in certain situations due to the way it mimics the display_id generation

Say, display_id = max(previous display id) + 1 & unfortunately 5 operations grab the same value before any of them get a chance to update it back!

This behavior would not be noticed in production as the underlying service ensures uniqueness :slight_smile: ! Regardless, I have noted this issue in FDK and will share it with the team for broader attention.