Errors when API URL is wrong is hard to understand

[tkrugg]

When API URL is wrong, the following error is returned.

Run TryGhost/[email protected]
Error [InternalServerError]: Invalid Version: null
    at /home/runner/work/_actions/TryGhost/action-deploy-theme/v1.5.0/dist/index.js:8160:33
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async main (/home/runner/work/_actions/TryGhost/action-deploy-theme/v1.5.0/dist/index.js:2009:9) {
  context: null,
  type: 'InternalServerError',
  details: null,
  property: null,
  help: null,
  code: null,
   ...
  ghostErrorCode: null
}

It should be something more indicative of the error.

[ErisDS]

What do you mean by "wrong"? 🤔 Please can you provide reproduction steps?

[tkrugg]

Just that it's not the right URL

[ErisDS]

Hi @tkrugg, I don't have enough information to reproduce the issue.

As shown in many of the issues that get raised like these: https://github.com/TryGhost/action-deploy-theme/issues/43 or https://github.com/TryGhost/action-deploy-theme/issues/67

When the URL is incorrect, the action fails with a 404 Not Found error:

Error: Request failed with status code 404
    at createError (/home/runner/work/_actions/TryGhost/action-deploy-theme/v1.4.1/dist/index.js:975:15)
    at settle (/home/runner/work/_actions/TryGhost/action-deploy-theme/v1.4.1/dist/index.js:8530:12)
    at IncomingMessage.handleStreamEnd (/home/runner/work/_actions/TryGhost/action-deploy-theme/v1.4.1/dist/index.js:[95](https://github.com/ErisDS/Alto-Emily/runs/7732213706?check_suite_focus=true#step:3:96)59:11)
    at IncomingMessage.emit (events.js:326:22)
    at endReadableNT (_stream_readable.js:1241:12)
    at processTicksAndRejections (internal/process/task_queues.js:84:21) {
  isAxiosError: true,
  toJSON: [Function]

So I am assuming you have some different issue where the exact URL or way that the URL is incorrect causes a different error.

Please can you provide exact reproduction steps, and explain how the URL is invalid?

Thanks.

[tkrugg]

Yes, in my case the calling the URL resolved with 200, but it returned an unexpected payload. I guess we can close for now, it's probably not an issue encountered often.