Hi all, I’m here with an update about our GET /workspaces/{workspace_gid}/tags endpoint. Some of you may have encountered a lot of slow responses or even 504 Gateway Timeout errors when listing tags in a workspace, and we’re changing how this endpoint works to prevent this issue. In short this endpoint will no longer hide empty tags.
Right now, when you attempt to list all tags in a workspace, the API filters the results to only include tags that have tasks in them. Looking into some old code while investigating a separate issue with tags, I noticed that the behavior of fetching tags in a workspace used to be different. When we first launched tags in the API back in 2012, this query would return all tags, not just non-empty tags. In 2016, an engineer working on the new “fast API” mistakenly implemented the new version of these endpoints with the additional filter. We believe this was the result of some confusion—in the web app, the typeaheads will hide empty tags, and so that behavior was added here too. However, the API already has a separate typeahead endpoint that was already (and will continue to) hide empty tags, so we believe this filtering on the GET /workspaces/{workspace_gid}/tags is incorrect.
What does this mean for you? Two main things:
- This endpoint will be much faster and will time out far less frequently. In order to determine if a tag is non-empty from the perspective of a user, we would have to query for tasks with that tag and run access control rules on them until we found a visible task. If tags were empty and filtered out, we’d need to query for more tags, query for their tasks, and repeat the process until we had enough for the API response. This is extremely expensive, especially for workspaces with lots and lots of empty tags. (We regularly hear of timeouts on this endpoint only to discover that the workspace had upwards of 25,000 empty tags in it.) By not applying this filter, we never need to perform these queries and the requests become cheap to fulfill.
- You may see many, many more tags in responses from this endpoint. Because the web app filters out empty tags from the typeahead, it is very easy for users to add a tag to a task, then remove it and never see the tag again. When they type in the name of that tag again, the typeahead doesn’t return the existing (empty) tag, and so the user ends up creating a new tag instead. However, to mitigate this issue, we are also launching the ability to delete tags in the API via
DELETE /tags/{tag_gid}. If you suddenly receive a problematic number of tags for a given workspace, you can now make the decision about what to keep and what to delete. We unfortunately cannot automatically delete empty tags, as they are still valid and visible, and can still be referenced directly by ID even if they don’t appear in the list of results for a workspace.
We’re sorry we had this mistake in production for four years, and we hope that this adjustment will lead to less confusion and better performance. The change will go into effect in about two weeks. As always, we’ll be watching this thread for feedback and will respond to any questions we can.
