Forks are not listed in the upstream repository's "Forks" page because they have not been indexed on the Search server
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
When a new repository is created as a fork of an existing repository, the new repo will be listed in the "Forks" page of the parent (also known as "upstream") repo.
However, if the new fork has not been indexed on the Search server (Elasticsearch or OpenSearch) for any reason (for example: if there are issues related to indexing), the fork will not be listed in the upstream's "Forks" page.
Click here for more details
When the "Forks" page of a repo is accessed, a request is made to the search server to retrieve the forks using the following endpoint:
request 1
1
/rest/search/latest/projects/<PROJECT_KEY>/repos/<REPO_SLUG>/forksThis endpoint retrieves the forks for the given PROJECT_KEY and REPO_SLUG.
If a valid JSON response is received, the application will use that data.
Sample request
1
curl -u <USER> https://bitbucket.myhost.com/rest/search/latest/projects/projects/PRJ1/repos/my-app/forksSample response
The JSON response below shows two forks for the PRJ1/my-app repo, which are: ~ADMIN1/my-app and ~ADMIN1/my-app-fork2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
{
"size": 2,
"limit": 25,
"isLastPage": true,
"values": [
{
"slug": "my-app",
"id": 43,
"name": "my-app",
"description": "this is a fork",
"scmId": "git",
"state": "AVAILABLE",
"statusMessage": "Available",
"forkable": true,
"origin": {
"slug": "my-app",
"id": 22,
"name": "my-app",
"description": "Test repo",
"scmId": "git",
"state": "AVAILABLE",
"statusMessage": "Available",
"forkable": true,
"project": {
"key": "PRJ1",
"id": 22,
"name": "Project1",
"public": false,
"type": "NORMAL",
"links": {
"self": [
{
"href": "https://bitbucket.myhost.com/projects/PRJ1"
}
]
}
},
"public": true,
"links": {
"clone": [
{
"href": "https://bitbucket.myhost.com/scm/prj1/my-app.git",
"name": "http"
},
{
"href": "ssh://git@bitbucket.myhost.com:7999/prj1/my-app.git",
"name": "ssh"
}
],
"self": [
{
"href": "https://bitbucket.myhost.com/projects/PRJ1/repos/my-app/browse"
}
]
}
},
"project": {
"key": "~ADMIN1",
"id": 1,
"name": "Admin1",
"type": "PERSONAL",
"owner": {
"name": "admin1",
"emailAddress": "admin1@test.com",
"id": 1,
"displayName": "Admin1",
"active": true,
"slug": "admin1",
"type": "NORMAL",
"links": {
"self": [
{
"href": "https://bitbucket.myhost.com/users/admin1"
}
]
}
},
"links": {
"self": [
{
"href": "https://bitbucket.myhost.com/users/admin1"
}
]
}
},
"public": false,
"links": {
"clone": [
{
"href": "ssh://git@bitbucket.myhost.com:7999/~admin1/my-app.git",
"name": "ssh"
},
{
"href": "https://bitbucket.myhost.com/scm/~admin1/my-app.git",
"name": "http"
}
],
"self": [
{
"href": "https://bitbucket.myhost.com/users/admin1/repos/my-app/browse"
}
]
}
},
{
"slug": "my-app-fork2",
"id": 643,
"name": "my-app-fork2",
"description": "this is another fork",
"scmId": "git",
"state": "AVAILABLE",
"statusMessage": "Available",
"forkable": true,
"origin": {
"slug": "my-app",
"id": 22,
"name": "my-app",
"description": "Test repo",
"scmId": "git",
"state": "AVAILABLE",
"statusMessage": "Available",
"forkable": true,
"project": {
"key": "PRJ1",
"id": 22,
"name": "Project1",
"public": false,
"type": "NORMAL",
"links": {
"self": [
{
"href": "https://bitbucket.myhost.com/projects/PRJ1"
}
]
}
},
"public": true,
"links": {
"clone": [
{
"href": "https://bitbucket.myhost.com/scm/prj1/my-app.git",
"name": "http"
},
{
"href": "ssh://git@bitbucket.myhost.com:7999/prj1/my-app.git",
"name": "ssh"
}
],
"self": [
{
"href": "https://bitbucket.myhost.com/projects/PRJ1/repos/my-app/browse"
}
]
}
},
"project": {
"key": "~ADMIN1",
"id": 1,
"name": "Admin1",
"type": "PERSONAL",
"owner": {
"name": "admin1",
"emailAddress": "admin1@test.com",
"id": 1,
"displayName": "Admin1",
"active": true,
"slug": "admin1",
"type": "NORMAL",
"links": {
"self": [
{
"href": "https://bitbucket.myhost.com/users/admin1"
}
]
}
},
"links": {
"self": [
{
"href": "https://bitbucket.myhost.com/users/admin1"
}
]
}
},
"public": false,
"links": {
"clone": [
{
"href": "ssh://git@bitbucket.myhost.com:7999/~admin1/my-app-fork2.git",
"name": "ssh"
},
{
"href": "https://bitbucket.myhost.com/scm/~admin1/my-app-fork2.git",
"name": "http"
}
],
"self": [
{
"href": "https://bitbucket.myhost.com/users/admin1/repos/my-app-fork2/browse"
}
]
}
}
],
"start": 0
}Note that if Bitbucket does not receive a valid response (for example, if the the search server is unavailable), the application will perform another request that does not involve the search server to retrieve the forks. It will call the following endpoint:
request 2
1
/rest/api/1.0/projects/<PROJECT_KEY>/repos/<REPO_SLUG>/forksBut as long as the response for the first request to search server is a valid JSON object, Bitbucket will use that data from the first request.
Diagnosis
The first step is check if there are any issues on the search server.
Please refer to Troubleshooting steps for Bitbucket Server Code Search for procedures for diagnosing possible search server issues.
Case 1
One possible scenario where new repos are not getting indexed is when the search server has set itself to "read-only" mode because it detected that it is running low on disk space.
Please see Elasticsearch reports HTTP status 403 in bitbucket logs for further info.
The next step would be to analyze the requests made from the Bitbucket UI through the following procedures:
Generate a HAR file while loading the "Forks" page of the upstream repo
Check the browser's Console logs for any error messages
In the HAR file, look for the
/rest/search/latest/projects/<PROJECT_KEY>/repos/<REPO_SLUG>/forksendpoint and check whether the JSON response returns the expected forks or not
Cause
Forks are not displayed if they have not been indexed on the search server.
Case 1
For this case, the fork was not indexed because the search server has set itself to "read-only" mode due to low disk space.
Resolution
Case 1
Please follow the resolution procedures mentioned in: Elasticsearch reports HTTP status 403 in bitbucket logs.
Was this helpful?