Open adamk72 opened 1 year ago
I pulled this code down and tinkered with things to find that with apiVersion
2 and a non-stringified options payload, all works well. Either stringifying or apiVersion
3 (which requires a stringified payload, so same thing) causes an error to happen.
I saw that one could customize the request
function, so I replaced it with this:
function internalRequest(options) {
return new Promise((resolve, reject) => {
_request(options.uri, options, (err, httpResponse) => {
if (err) {
reject(err);
} else {
if (httpResponse.statusCode >= 400) {
reject(httpResponse.body);
}
// for compatibility with request-promise
resolve(httpResponse.body);
}
});
});
}
An almost exact copy of the default request
function expect for it only takes in a single option
argument instead of a (uri, options)
tuple and I pull the uri
off of the options
object. This, I'm glad to say, worked. While I have some speculation on why the default function doesn't work when passed a stringified object, I'm satisfied that it works.
Because, I have other things to now debug. Unfortunately, when I copy and paste that new working function over into my own code... it doesn't work. But I do see a delightfully new set of console log output that I'm not sure where it came from... so, that at least is something different.
Hey @adamk72, thank you for the detailed description. If you get it working the way you expect then feel free to open an MR or post the solution here! I wouldn't expect that modifying request
in that way would do anything, but maybe I'm missing something
Success!
I'm not clear on what I was doing wrong in the past that originally prompted me to make this post, but I suspect it had to do with a combination of the apiVersion
s being mixed up with the content type I was trying to deliver, in conjunction with stringifying things.
However, in the most recent testing, I noticed that I had not applied JSON.stringify
in the jira-test.js file for node-jira-client and things worked fine. That was the last bit to get it working on my side, removing my original JSON.stringify
. It was actually in writing a followup post here that I noticed the discrepancy. One log showed me one thing, another something different. Enough for that a-ha moment! 💡
Really, it was just a question of sorting through the different error types Atlassian was throwing back my way. 🙄
So it appears all is hunky-dory.
I know this asking a bit beyond what is expected of an open source project, but since it was a red herring in my search. perhaps you can clear something up for for me. No worries if you can't/don't want to. In any case, Thanks for letting me rubber duck this problem out here! 🐣
So here's the ask:
doRequest
only passes an options
object, but it passes it to the uri
argument of the request
function (which takes a uri
and options
argument in that order), so it appears to me that:
uri
is populated by options
.A console log reveals that as being true:
{
auth: {
user: '***',
pass: '***'
},
rejectUnauthorized: true,
method: 'POST',
uri: 'https://***/rest/api/3/issue',
json: true,
followAllRedirects: true,
body: { fields: [Object] }
}
} { options: undefined }
Am I reading that right? What am I missing that this works? I'd expect uri
to be a string, and not an object in this case. I consider myself decent at TS, but am free to admit I get lost without my types to help guide me in JS. 😄
Hey, there!
I'm working on syncing GitHub issues over to Jira using GH actions. At a basic level, I have this working just fine; authentication and such aren't the problem.
What I'd like to do is to format the descriptions I'm passing to Jira with bold, headers, etc. Passing raw Markdown syntax doesn't behave as expected (such as
## Title
for a header), so I've been trying to pass in an Atlassian Document Format payload.The error I'm getting is:
My payload looks like this (this is the log result right after the object has been
JSON.stringify()
'd):When I pass that payload to the Postman app (with a
POST
command to '{{jiraUrl}}/rest/api/3/issue/') this works fine. My Jira instance updates with no trouble and with the expected formatting.This is what the client setup looks like:
At first I had the wrong
apiVersion
(using 2 instead of 3) in the code, but I corrected that as well, and am not seeing a way to get deeper into the error (I'm assuming it's from Atlassian, but since I don't see it when using Postman, I can't see what I might be doing wrong). I see that the underlying code is usingpostman-request
so I'd think there isn't a major difference in implementations. Looking for a suggestion to see if there's a way to further debug this, or if you know why this might be happening.Thanks for your time in advance. I'm going to keep trying things to see what arises.