Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No way to access full error response body #296

Open
cubeghost opened this issue Feb 19, 2024 · 2 comments
Open

No way to access full error response body #296

cubeghost opened this issue Feb 19, 2024 · 2 comments

Comments

@cubeghost
Copy link
Contributor

According to the API docs, when dealing with 4xx errors, the body's response object sometimes contains more information about the error. It would be really useful to be able to access the full response from error callbacks or rejections in this library, but I'm not sure if it's possible at the moment.

The Node HTTP response object is passed as the third argument to callback, but by the time callback is called, the response body stream has already been consumed, so we can't access it. One workaround could be to pipe responseData back into the response stream right before calling callback.

Since it seems like callback is being deprecated, another approach could be to extend the Error class to add a property for the response body, which would give access to the full response when handling async/promise rejections.

@sirreal
Copy link
Member

sirreal commented Feb 22, 2024

Thanks for the issue @cubeghost, it seems valid and it would be a nice improvement. Would you be interested in working on it?

It's clear you've spent some time looking at the code 🙂 so I have a few questions. The callback form is indeed deprecated. Having to deal with both callbacks and promises introduces a lot of complexity around response handling. Would it simplify the implementation of this feature if we first remove callbacks in a breaking change?

Most API responses from tumblr have the form { meta, response, errors?: Array<string> }, it might be interesting to expose those errors, although providing access to the response body is simple and consistent and we wouldn't need to worry about differences between different endpoints. A new class may be a good way to go.

@net-tech
Copy link

Hi, is there any status update on this? I get 400 bad request with the following

const content: NpfContentBlock[] = [
		{
			type: "text",
			text: parsed.data.contentSnippet
		}
	]
	
// It does in the error case
if (media.endsWith(".mp4")) {
				content.push({
					type: "video",
					media: {
						url: media
					},
				})
			}
			
	const result = await tumblrClient.createPost(TUMBLR_BLOG, {
		content,
		tags: TUMBLR_HASHTAGS,
		source_url: parsed.data.tweetUrl,
		date: parsed.data.postedAt
	})		

and it would be interesting to see where I messed up the format given that I do not get any TypeScript errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants