Listing items doesn't display all items

mxldevs

Having some trouble figuring out this issue.
I'm using the REST API to send requests to our Connect server.

Accessing 1password through the browser I set up a test vault with two items.
Using the API, I send a GET request to /v1/vaults/{vaultUUID}/items and it returns the two items

Next I send a POST request to the same endpoint with an object and I verify that the item has been created successfully in the vault.
There are now three items in the vault.

When I send a GET request again, however, it only shows the two items from before.

Could this be a cache issue?

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided

LuukM

Are you using the Docker Compose image as a Connect server?

What i found, was that there is not really a functional sync in place. It syncs everytime the container / volume is created, not when it is restarted.

What helped me, was removing the container and volume (docker volume rm {container}). This will force a new sync, giving you all the latest items

Joris_1P

Hi @mxldevs,

Thank you for reaching out. As LuukM points out, we have seen a few reports about Connect not always staying fully in sync with the server. That could also explain what you are seeing here.

Unfortunately, we have not yet been able to reproduce this problem ourselves. So if you by any chance still have the logs of the connect-api and connect-sync container from the moment that you had this problem (preferably up until when they were started), that could give us some insights into what is going on here.

In the meantime, we're also working on some general improvements that should help address these problems.

Joris

mxldevs

Thanks @LuukM and @Joris_1P . We saw there was a sync issue and deleting the entire volume seems to have done the trick. It also seems to have allowed for further syncing to occur which is odd but at least it works as expected.

Joris_1P

Thanks for sharing that info. Good to hear it's resolved for you.

Yesterday we were finally able to reproduce a very similar scenario. We are currently working on a fix, but in the meantime, deleting the volume should indeed resolve the issue. If you delete the volume, the problem should not reappear.