Skip to content
This repository has been archived by the owner on Jul 12, 2019. It is now read-only.

Fix TypeError on requestUrl.indexOf #59

Merged
merged 2 commits into from
Dec 20, 2017
Merged

Conversation

eliangcs
Copy link
Member

@eliangcs eliangcs commented Dec 19, 2017

Encountered the following error when I was working on zapier/zapier-platform-cli#208.

  1) Searches - Full Search
       should get an object:
     TypeError: requestUrl.indexOf is not a function
      at Object.object.request (node_modules/zapier-platform-core/src/tools/create-http-patch.js:25:22)
      at Request.start (node_modules/request/request.js:748:32)
      at Request.end (node_modules/request/request.js:1512:10)
      at end (node_modules/request/request.js:561:14)
      at Immediate.<anonymous> (node_modules/request/request.js:575:7)
      at Function.module.exports.loopWhile (node_modules/deasync/index.js:72:22)
      at node_modules/deasync/index.js:44:19
      at Object.request (node_modules/zapier-platform-legacy-scripting-runner/z.js:97:22)
      at Object.full_search_search (scripting.js:97:26)
      at e (node_modules/zapier-platform-legacy-scripting-runner/index.js:108:33)
      at Object.runEvent (node_modules/zapier-platform-legacy-scripting-runner/index.js:32:35)
      at getList (searches/full_search.js:23:6)
      at execute (node_modules/zapier-platform-core/src/execute.js:68:12)
      at node_modules/zapier-platform-core/src/create-command-handler.js:26:12
      at Object.beforeMiddleware.then.newInput (node_modules/zapier-platform-core/src/middleware.js:91:24)
      at bound (domain.js:280:14)
      at Object.runBound (domain.js:293:12)

Turned out that options.url is an object as opposed to a string in this failed test case. According to http.request's doc, options is either a string (URL) or an object (request options). It doesn't say anything about options.url. I'm not sure why the previous implementation did options.url || options.href, but here we go.

@grajagandev
Copy link

I love Zapier - great product. Would you be interested in software that automatically finds TypeErrors like this? I am building Fuzz Stati0n to do that (free for OSS) - please take a look and consider signing up for our newsletter to keep in touch.

Copy link
Contributor

@xavdid xavdid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the .url thing is a breaking change, we should fix it. if not, you're probably good to go. the string thing is super not worth its own commit.

@@ -18,10 +18,20 @@ const createHttpPatch = event => {

// Proxy the request method
object.request = (options, callback) => {
const requestUrl =
options.url ||
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this isn't re-added anywhere, right? So this will break existing code that is passing in objects with a .url property, which may not be intended.

Copy link
Member Author

@eliangcs eliangcs Dec 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand the code correctly, object.request is to patch Node's http.request method, which does not accept an object with a .url property:

> let http = require('http');
undefined
> http.request({url:'http://httpbin.org/get'});
...
> Error: connect ECONNREFUSED 127.0.0.1:80
    at Object.exports._errnoException (util.js:1018:11)
    at exports._exceptionWithHostPort (util.js:1041:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)

If the point is to follow http.request's spec 100%, then we should not accept an object with a .url property here neither. But I'm not sure if any existing code or library is doing that (passing an object with a .url property). Any clues about that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, fair deal! should be safe to go then.

} else {
requestUrl =
options.href ||
`${(options.protocol || 'https:') + '//'}${options.host}${
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super minor, but you can have the // in the template string itself instead of doing the addition operation:

${(options.protocol || 'https:')}//${options.host}...

Copy link
Member Author

@eliangcs eliangcs Dec 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion. Fixed in e754267.

@eliangcs eliangcs merged commit 167abac into master Dec 20, 2017
@eliangcs eliangcs deleted the fix-http-patch-indexOf-error branch December 20, 2017 08:07
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants