Use Jira API to post a request for new Jira creation, "read ETIMEDOUT" is returned

[Zhishang Zheng]

Use Jira API to post a request for new Jira creation, although we see a new Jira ticket is created, the request seems successful, we get a "read ETIMEDOUT":

```

syscall: 'read',

code: 'ETIMEDOUT',

errno: 'ETIMEDOUT',

```

Since there is a timeout, we could not provide a request id for you.

We would provide the created Jira, and the time when the issue occurs.

Jira: https://synaptics.atlassian.net/browse/VSSDK-33831

Time: March 17, 2025 at 3:36 PM(GMT+8)

[Vishal Biyani]

@Zhishang Zheng 

Can you share more details like which JIRA APIs are you using?

What is the payload that you are passing?

[Zhishang Zheng]

@Vishal Biyani , could you kindly take a look at this data? Sorry for the formation..

2025-03-17 03:35:49PM API Request Original Error: AxiosError: read ETIMEDOUT
at Function.AxiosError.from (/usr/src/app/node_modules/axios/dist/node/axios.cjs:836:14)
at RedirectableRequest.handleRequestError (/usr/src/app/node_modules/axios/dist/node/axios.cjs:3010:25)
at RedirectableRequest.emit (events.js:314:20)
at ClientRequest.eventHandlers.<computed> (/usr/src/app/node_modules/follow-redirects/index.js:14:24)
at ClientRequest.emit (events.js:314:20)
at TLSSocket.socketErrorListener (_http_client.js:427:9)
at TLSSocket.emit (events.js:314:20)
at emitErrorNT (internal/streams/destroy.js:92:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
at processTicksAndRejections (internal/process/task_queues.js:84:21) {
syscall: 'read',
code: 'ETIMEDOUT',
errno: 'ETIMEDOUT',
config: {
transitional: {
silentJSONParsing: true,
forcedJSONParsing: true,
clarifyTimeoutError: false
},
adapter: [ 'xhr', 'http' ],
transformRequest: [ [Function: transformRequest] ],
transformResponse: [ [Function: transformResponse] ],
timeout: 0,
xsrfCookieName: 'XSRF-TOKEN',
xsrfHeaderName: 'X-XSRF-TOKEN',
maxContentLength: -1,
maxBodyLength: -1,
env: { FormData: [Function], Blob: null },
validateStatus: [Function: validateStatus],
headers: AxiosHeaders {
Accept: 'application/json, text/plain, */*',
'Content-Type': 'application/json',
Authorization: 'Basic Hidden value',
'X-Atlassian-Token': 'no-check',
'User-Agent': 'axios/1.4.0',
'Content-Length': '2477',
'Accept-Encoding': 'gzip, compress, deflate, br'
},
paramsSerializer: { serialize: [Function: bound paramSerializer] },
baseURL: 'https://synaptics.atlassian.net',
url: 'https://synaptics.atlassian.net/rest/api/3/issue',
method: 'post',
data: '{"fields":{"summary":"[CI][Hidden value][Hidden value][Hidden value][Hidden value] Hidden value auto test failed","issuetype":{"name":"Bug"},"project":{"id":"10750"},"customfield_10569":{"version":1,"type":"doc","content":[{"type":"paragraph","content":[{"type":"text","text":"[Testing objective]"},{"type":"hardBreak"},{"type":"text","text":"Hidden value auto test"}]},{"type":"paragraph","content":[{"type":"text","text":"[Testing Steps]"},{"type":"hardBreak"},{"type":"text","text":"Fill with suite.log"}]},{"type":"paragraph","content":[{"type":"text","text":"[Actual Results]"},{"type":"hardBreak"},{"type":"text","text":"Fill Actual Results here"}]},{"type":"paragraph","content":[{"type":"text","text":"[Expected Results]"},{"type":"hardBreak"},{"type":"text","text":"Fill Expect Results here"}]},{"type":"paragraph","content":[{"type":"text","text":"[Frequency of occurrence]"}]},{"type":"paragraph","content":[{"type":"text","text":"[Additional Information]"},{"type":"hardBreak"},{"type":"text","text":"1.AndroidBootloaderTest auto test first failed at build 202503140405. Last pass at build:","marks":[{"type":"textColor","attrs":{"color":"#bf2600"}}]},{"type":"hardBreak"},{"type":"text","text":"Log: "},{"type":"text","text":"Hidden Value","marks":[{"type":"link","attrs":{"href":"Hidden Value"}}]}]},{"type":"paragraph","content":[{"type":"text","text":"[Testing Environment]"},{"type":"hardBreak"},{"type":"text","text":"Image: "},{"type":"text","text":"Hidden Value","marks":[{"type":"link","attrs":{"href":"Hidden Value"}}]}]}]},"reporter":{"id":"5a7bef10ddc5483fd4677239"},"assignee":{"id":"5a7bef10ddc5483fd4677239"},"customfield_10586":[{"value":"Platypus"}],"customfield_10960":[{"value":"Android_U_GMS"}],"components":[{"name":"AMP"}],"customfield_10293":{"value":"S2_Critical"},"versions":[{"name":"HART 25r1"}],"customfield_10382":[{"name":"5a7bef10ddc5483fd4677239"}]}}',
httpsAgent: Agent {
_events: [Object: null prototype],
_eventsCount: 2,
_maxListeners: undefined,
defaultPort: 443,
protocol: 'https:',
options: [Object],
requests: {},
sockets: [Object],
freeSockets: {},
keepAliveMsecs: 1000,
keepAlive: false,
maxSockets: Infinity,
maxFreeSockets: 256,
maxTotalSockets: Infinity,
totalSocketCount: 1,
scheduling: 'fifo',
maxCachedSessions: 100,
_sessionCache: [Object],
[Symbol(kCapture)]: false
}
},
request: Writable {
_writableState: WritableState {
objectMode: false,
highWaterMark: 16384,
finalCalled: false,
needDrain: false,
ending: false,
ended: false,
finished: false,
destroyed: false,
decodeStrings: true,
defaultEncoding: 'utf8',
length: 0,
writing: false,
corked: 0,
sync: true,
bufferProcessing: false,
onwrite: [Function: bound onwrite],
writecb: null,
writelen: 0,
afterWriteTickInfo: null,
bufferedRequest: null,
lastBufferedRequest: null,
pendingcb: 0,
prefinished: false,
errorEmitted: false,
emitClose: true,
autoDestroy: false,
bufferedRequestCount: 0,
corkedRequestsFree: [Object]
},
writable: true,
_events: [Object: null prototype] {
response: [Function: handleResponse],
error: [Function: handleRequestError],
socket: [Function: handleRequestSocket]
},
_eventsCount: 3,
_maxListeners: undefined,
_options: {
maxRedirects: 21,
maxBodyLength: Infinity,
protocol: 'https:',
path: '/rest/api/3/issue',
method: 'POST',
headers: [Object: null prototype],
agents: [Object],
auth: undefined,
family: undefined,
lookup: undefined,
beforeRedirect: [Function: dispatchBeforeRedirect],
beforeRedirects: [Object],
hostname: 'synaptics.atlassian.net',
port: '',
agent: [Agent],
nativeProtocols: [Object],
pathname: '/rest/api/3/issue'
},
_ended: false,
_ending: true,
_redirectCount: 0,
_redirects: [],
_requestBodyLength: 2477,
_requestBodyBuffers: [ [Object] ],
_onNativeResponse: [Function],
_currentRequest: ClientRequest {
_events: [Object: null prototype],
_eventsCount: 7,
_maxListeners: undefined,
outputData: [],
outputSize: 0,
writable: true,
_last: true,
chunkedEncoding: false,
shouldKeepAlive: false,
_defaultKeepAlive: true,
useChunkedEncodingByDefault: true,
sendDate: false,
_removedConnection: false,
_removedContLen: false,
_removedTE: false,
_contentLength: null,
_hasBody: true,
_trailer: '',
finished: false,
_headerSent: true,
socket: [TLSSocket],
connection: [TLSSocket],
_header: 'POST /rest/api/3/issue HTTP/1.1\r\n' +
'Accept: application/json, text/plain, */*\r\n' +
'Content-Type: application/json\r\n' +
'Authorization: Basic Hidden value\r\n' +
'X-Atlassian-Token: no-check\r\n' +
'User-Agent: axios/1.4.0\r\n' +
'Content-Length: 2477\r\n' +
'Accept-Encoding: gzip, compress, deflate, br\r\n' +
'Host: synaptics.atlassian.net\r\n' +
'Connection: close\r\n' +
'\r\n',
_keepAliveTimeout: 0,
_onPendingData: [Function: noopPendingOutput],
agent: [Agent],
socketPath: undefined,
method: 'POST',
insecureHTTPParser: undefined,
path: '/rest/api/3/issue',
_ended: false,
res: null,
aborted: false,
timeoutCb: null,
upgradeOrConnect: false,
parser: null,
maxHeadersCount: null,
reusedSocket: false,
host: 'synaptics.atlassian.net',
protocol: 'https:',
_redirectable: [Circular],
[Symbol(kCapture)]: false,
[Symbol(kNeedDrain)]: false,
[Symbol(corked)]: 0,
[Symbol(kOutHeaders)]: [Object: null prototype]
},
_currentUrl: 'https://synaptics.atlassian.net/rest/api/3/issue',
[Symbol(kCapture)]: false
},
cause: Error: read ETIMEDOUT
at TLSWrap.onStreamRead (internal/stream_base_commons.js:209:20) {
errno: 'ETIMEDOUT',
code: 'ETIMEDOUT',
syscall: 'read'
}
}

[Vishal Biyani]

The way the details have been dumped can't be comprehended. With the availability of tools like ChatGPT this task has become lot easier.

Looks like you are using Axios with Node.js. The payload that is being used may be too big.

Can you try this code and see if this helps you move forward? if this works, then you can expand the payload till it breaks.

const axios = require('axios');
const https = require('https');
const axiosRetry = require('axios-retry');

// Setup retry mechanism
axiosRetry(axios, {
retries: 3,
retryDelay: (retryCount) => retryCount * 2000, // Exponential backoff
retryCondition: (error) => axiosRetry.isNetworkOrIdempotentRequestError(error),
});

// Configure Axios instance
const apiClient = axios.create({
baseURL: 'https://synaptics.atlassian.net/rest/api/3',
timeout: 10000, // 10-second timeout
httpsAgent: new https.Agent({ keepAlive: true }),
headers: {
'Content-Type': 'application/json',
Accept: 'application/json',
Authorization: 'Basic <hidden>',
'X-Atlassian-Token': 'no-check',
'User-Agent': 'axios/1.4.0',
},
});

// Define the payload
const issuePayload = {
fields: {
summary: '[CI] Test Failed',
issuetype: { name: 'Bug' },
project: { id: '10750' },
description: {
type: 'doc',
version: 1,
content: [
{ type: 'paragraph', content: [{ type: 'text', text: 'Test details here' }] },
],
},
reporter: { id: '5a7bef10ddc5483fd4677239' },
assignee: { id: '5a7bef10ddc5483fd4677239' },
},
};

// Send the request with error handling
(async () => {
try {
const response = await apiClient.post('/issue', issuePayload);
console.log('Issue created:', response.data.key);
} catch (error) {
console.error('Failed to create issue:', error.message);
if (error.code === 'ETIMEDOUT') {
console.error('Request timed out. Check network or server status.');
}
}
})();

[Zhishang Zheng]

@Vishal Biyani 

In our code there is already retry logic. But as we find out, sometimes even when the new Jira is successfully created via API http request, the request returns a timeout, then retry will create a duplicate issue.

So using retry might be a dangerous option for us.

I think if you could get the request id from below info, then a lot of details could be achieved from it. Not sure whether it's possible or not to get the id though.

Jira: https://synaptics.atlassian.net/browse/VSSDK-33831

Time: Around March 17, 2025 at 3:36 PM(GMT+8)

[Vishal Biyani]

Can you try using below and see if you get the request id?

// Extracting Jira's request ID from headers
const jiraRequestId = response.headers['x-arequestid'];

[Zhishang Zheng]

@Vishal Biyani When this issue occurs, we could not get a "response", so no way to get the request id. All the info we get is as pasted in the above comment: https://community.atlassian.com/forums/Jira-questions/Re-Re-Use-Jira-API-to-post-a-request-for-new-Jira-creat/qaq-p/2976108/comment-id/1113076#M1113076.

[Vishal Biyani]

So, if the issue is getting created, however, the response from JIRA Cloud is taking more time to come back, due to some network issues or whatever, then one of the option is to try and increase the timeout and see if it helps.

Other than that, the other option is to check recently created issue if the request timed out. but there is no guarantee it will be a foolproof method unless it can be ensured that issues being queried will only be created by this API call (like using some specific labels etc). then decision can be made to retry or not depending on if the issue is created or not.

What do you think?

[Zhishang Zheng]

@Vishal Biyani , actually no timeout is set for our request, so increasing the timeout may not be a proper option, but we will try if it helps.

As for the "to check recently created issue if the request timed out", this is not possible.

From 11th March(around that time, may not be absolutely accurate), we started to see this random issue during API request with multiple scenarios. For instance, post request to create a new Jira, get request to query Jira info, post request to delete an attachment in Jira.
So the scenario is complex, it's not possible to check whether the request is "actually" successful or not without a lot of code.

Meanwhile, we knew there were some changes in Jira server side recently, such as this:

https://community.atlassian.com/forums/Jira-questions/The-request-could-not-be-satisfied-custom-jira/qaq-p/2512143.

So is it possible that the random request failure issue is also caused by a recent Jira update?

[Vishal Biyani]

difficult for me to say. Better to reach out to Atlassian support and have them take a look

[Zhishang Zheng]

@Vishal Biyani , thanks a lot for these info. If possible, could you kindly help @ someone to support? We do not know whom to reach to.

[Zhishang Zheng]

Hi @bmcalary , sorry to bother you, could you help take a look at this issue?

Unfortunately we could not provide the request id since we were unable to get it.

The request data is here:

https://community.atlassian.com/forums/Jira-questions/Re-Re-Use-Jira-API-to-post-a-request-for-new-Jira-creat/qaq-p/2976108/comment-id/1113076#M1113076

And is it possible that you get the request id from the Jira that was created?

Jira: https://synaptics.atlassian.net/browse/VSSDK-33831

Time: Around March 17, 2025 at 3:36 PM(GMT+8)

[bmcalary]

@Zhishang Zheng what is your axios `timeout` currently set to?

The log you shared shows your client was in "read" state which is awaiting a response from Jira, but gave up on your side due to encountering a timeout.

Try adding the following to your axios client config.

            timeout: 60000,
            httpsAgent: new https.Agent({ keepAlive: true }),

[Zhishang Zheng]

@bmcalary Sure, we'll try.

Meanwhile, just wondering, it is possible to get the request id from your side given the Jira ticket and the creation time? I think the request id will reveal a lot of info.

[bmcalary]

@Zhishang Zheng That issue was created by Atlassian ID 5a837474f3564698bccedeecc0066d45  Cloudfront ID kpiZ6SrP7tvqUDPWFPkhEEfSV_OKXqTEs6xZsomwG_EO4JpZDXHgXw== 

[Zhishang Zheng]

@bmcalary "kpiZ6SrP7tvqUDPWFPkhEEfSV_OKXqTEs6xZsomwG_EO4JpZDXHgXw==" this should be the request id, with it you should get a lot of info for that request.

How was that request? Anything wrong?

[bmcalary]

@Zhishang Zheng AWS logged it as a successful response with a 200 OK response code. The only thing somewhat interesting is that AWS logged the following:

* time-to-first-byte: 1.923s (this is how long it took from the receipt of the request till Atlassian sent the response to Cloudfront)

* time-taken: 6.923s (this is how long it took for the entire transaction)

Interestingly,

6.923-1.923 = 5s (this is the time Cloudfront spend trying to send you the response).

Is it possible you have a 5s timeout set in axiom?

Also, historically, when we see a long time-taken vs a short time-to-first-byte (like in this case) it means that the internet was interrupted between your client and Cloudfront, or there was extensive packet loss, or a proxy/firewall is in use on your end and it had a problem.

To dive deeper a Wireshark or tcpdump would be required, as this is beginning to look like an issue at the TCP layer.

[Zhishang Zheng]

@bmcalary Thanks a lot, we will check with the new info.

[Zhishang Zheng]

@bmcalary , after adding `keepAlive: true` and a timeout parameter, now the API http requests seem stable. Will keep monitoring a few more days.

[Zhishang Zheng]

After the update of adding timeout and "keepAlive" parameters, now the issue has not been met at our side for one week, this issue should have been fixed.

@Vishal Biyani @bmcalary  Thank you for your great help.