The problem with tags, and a solution

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.


Hi @Joe_Trollo,

First and foremost:
:clap: :clap: :clap: :clap: :clap: :clap:

This isn’t really an API question but what’s the reason that empty tags are hidden in the web app? If they were not hidden, you wouldn’t have the issue you describe:

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.

1 Like

I have absolutely no idea. I agree that not hiding them would curtail the excess of empty tags and might even be a better experience for users of the web app, but the original motivations far predate my time at Asana and the few more-tenured people I’ve asked about this can’t recall them either.

We got lots of timeouts with tags when developing our application Bridge24. For some clients, it takes more than a minute to get all tags. Hope this fix will resolve that problem. We’ll give it a try.


So, our customers with “timeout” of 60 seconds will now have a treeview with tons of tags to choose, 95% of them will return 0 tasks?
I think you may take time to delete tags created more than 90 days ago for example and never used in any task ever. not present in actions or anywhere else.
We fetch tags, and show them to our users to allow an easy “get by tag” query.
But now, I’m not sure that having most of them empty will be really useful!


Hi @Frederic_Malenfant, would the typeahead endpoint be more suited for your use case? It would allow users to type in the partial name of a tag and quickly see a list of matching, non-empty tags in their workspace.

In the meantime, I’ll investigate the feasibility of cleaning up just “old” empty tags. Thank you for the idea!


Yes, the typeahead is a great suggestion.
I talked with the team, we will probably offer tags that we know exists (based on recent tasks query), + typeahead.


Nevermind! Found the issue!!

When is this change scheduled to be pushed into production? Please let know.