Repository names greater than 62 characters are truncated

Issue #13403 open
Sergey Zhemzhitsky created an issue

Currently we have discovered that repository names are truncated if length of theirs names is greater than 62.

For example, consider the following name (62 chars)

repo-with-long-name-exceeding-62-chars-cant-be-found-using-api

This name works just fine and there are no any issues with it

$ curl -u '<user>:<password>' 'https://api.bitbucket.org/2.0/repositories/<team>/repo-with-long-name-exceeding-62-chars-cant-be-found-using-api' | jq . 
{
  ...
  "name": "repo-with-long-name-exceeding-62-chars-cant-be-found-using-api",
  "links": {
    ...
    "branches": {
      "href": "https://api.bitbucket.org/2.0/repositories/<team>/repo-with-long-name-exceeding-62-chars-cant-be-found-using-api/refs/branches"
    },
    ...
    "html": {
      "href": "https://bitbucket.org/<team>/repo-with-long-name-exceeding-62-chars-cant-be-found-using-api"
    },
    ...
  },
  ...
  "full_name": "<team>/repo-with-long-name-exceeding-62-chars-cant-be-found-using-api",
  ...
}

As you can see name and full_name as well as all the links are consistent with the original repository name.

Now rename the repository by appending to its name just one character to look like the following

repo-with-long-name-exceeding-62-chars-cant-be-found-using-api1

Then try to find it by its name and observe 404 http response code

$ curl -u '<user>:<password>' 'https://api.bitbucket.org/2.0/repositories/<team>/repo-with-long-name-exceeding-62-chars-cant-be-found-using-api1' | jq . 
{
  "error": {
    "message": "Repository <team>/repo-with-long-name-exceeding-62-chars-cant-be-found-using-api1 not found"
  }
}

although the repository cannot be found by its name, it can be found in the list of all the repositories

$ curl -u '<user>:<password>' 'https://api.bitbucket.org/2.0/repositories/<team>?pagelen=100' | jq '.values | .[] | select(.name == "repo-with-long-name-exceeding-62-chars-cant-be-found-using-api1")'
{
  ...
  "name": "repo-with-long-name-exceeding-62-chars-cant-be-found-using-api1",
  "links": {
    ...
    "branches": {
      "href": "https://api.bitbucket.org/2.0/repositories/<team>/repo-with-long-name-exceeding-62-chars-cant-be-found-using/refs/branches"
    },
    ...
    "html": {
      "href": "https://bitbucket.org/<team>/repo-with-long-name-exceeding-62-chars-cant-be-found-using"
    },
    ...
  },
  ...
  "full_name": "<team>/repo-with-long-name-exceeding-62-chars-cant-be-found-using",
  ...
}

and now we can see that its full name is

<team>/repo-with-long-name-exceeding-62-chars-cant-be-found-using

although the original name we just set is

repo-with-long-name-exceeding-62-chars-cant-be-found-using-api1

and all the links are inconsistent with the original name too.

Comments (6)

  1. Kaleb Elwert Account Deactivated

    It looks like the column which stores the repo slug is limited to 62 characters. If you look at the repo when browsing the site, the slug is limited there as well. This is counter-intuitive, but I don't think this corner case is something we are likely to devote the engineering effort to change.

    We do provide a uuid which can be used to look up any repo as well as the "links" attribute in any API responses, so you don't need to look up the url for any related fields yourself, which should make dealing with this strangeness a little bit easier.

  2. Sergey Zhemzhitsky reporter

    @kelwert I don't think that the issue connected with the limitations of column that stores repo slug. If you look at the repo name - it remains correct repo-with-long-name-exceeding-62-chars-cant-be-found-using-api1, i.e. stores 63 characters, but full repository name <team>/repo-with-long-name-exceeding-62-chars-cant-be-found-using is somehow truncated and this limitation is not so obvious as seems to be.

  3. Kaleb Elwert Account Deactivated

    In our database, the column which stores the slug is limited to 62 characters. The slug is what we use in the URL. I don't know why this arbitrary limitation was created, but it's unfortunately there. We store the slug separate from the name so we don't need to do the conversion on the fly when looking up repos.

    This will be left open (I was wrong changing it to wontfix), but we probably won't get to it very soon because it's more of a major change than we'd like, due to having to update one of our most frequently accessed tables (this will lock the table and potentially cause downtime), and there are a number of ways to work around it.

    I'll also see about getting our documentation updated to reflect this limitation.

  4. Log in to comment