Watch or Deploy command shows a timeout error message

[tauthomas01]

Problem

Me and a colleague received a UnhandledPromiseRejectionWarning: Error: read ECONNRESET message while using slate watch or slate deploy command. The problem is not always happening but intermittent.

Before the holidays, this was not happening and ever since I came back in beginning January, I received this timeout error once in a while.

Replication steps

1. Run yarn deploy or yarn start command. The error does not happen instantly but once in a while, the following message will be shown :

I will post more screenshots if I see error messages.

More Information

According to @t-kelly, this sounds like a ThemeKit error.

[jonathanmoore]

I can confirm the same issue on my end, and the issue came up at the same timeframe. It doesn't seem to cause any problems with yarn start, but the error does appear frequently.

On start

(node:7078) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): Error: read ECONNRESET (node:7078) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Intermittently after start

(node:7078) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 4): Error: connect ETIMEDOUT 23.227.37.162:443

[henrybarn]

Can confirm. Also an issue for yarn start for me.

[driespieters]

+1. Also on yarn start.

[justinmetros]

+1 confirm

(node:36966) UnhandledPromiseRejectionWarning: Error: connect ETIMEDOUT XX.XXX.XX.XXX:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1121:14)
(node:36966) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:36966) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

For me always seems to have the (net.js:1121:14) bit consistently.

Edit - I didnt know if that was my IP so I x'd it out but same numbers as those above.

[t-kelly]

Is this actually impacting your workflow at all? Just trying to gage how urgent this is.

[driespieters]

For me this causes a delay of +-1min when deploying.

[loiic-v]

+1 kind of annoying but not really a blocker issue

[jonathanmoore]

@t-kelly Zero impact on my workflow and I haven't encountered any delays.

[justinmetros]

In the middle of migrating our build structure to include Slate - but I can def say its a worrisome error. Hasn't blocked yet... but when we deploy we NEED it to be 100%.

Our Plus site is HIGH volume - errors are fine, but feedback on errors is always welcomed 💅

Note: this doesn't happen on my dev store with modest amounts of content. This happens only when deploying everything to an unpublished theme on production with the whole kit and kaboodle. We have about 75-100 pages and a good chunk of them have corresponding sections for those pages. Its a 220+ upload every deploy. Seems to tap out about halfway through then restart - but with min error messages.

Did a file get skipped? No way to know.

[t-kelly]

@justinmetros don't forget you can always yarn zip and upload the zip to Shopify in the admin panel

[justinmetros]

@t-kelly of course :) To add some color to this - all day long we have content editors across multiple teams adjusting theme settings.

Our workflow is pretty standard - DEV work is done in a dev theme, that is then pushed to staging theme aka the next 'release' ( where content editors have more than likely edited settings, so we ignore settings_data in slate-tools ( managing that file in git sucks, so we let Shopify handle it with its own versioning ). Then we do a deploy. When deploy is successful, we publish staging theme, rinse and repeat.

If the deploy fails, or skips a file, site is just too big to check everywhere, so we run it again until it doesnt error out. When it does hit an ECONNRESET or ETIMEOUT, would be cool get some feedback to know we didn't skip any files.

Not really a blocking issue, but I think its worth flushing out some of the terminal feedback if the Shopify team has the resources. Deploys are stressfull enough, haha :P

*edit a word or two

[CaseJnr]

Any update on this. I am currently experiencing this with yarn start.

[markdavies]

I have been seeing it consistently in the last few days too, it's not stopping us working but it's pretty inconvenient.

[isabellegalvao]

+1. Also on yarn start and watch, any update?

[CaseJnr]

Its caused due to https://v.shopify.com/slate/track being offline. To remove the error I added a return statement at the top of the event function on line 62 of node_modules/@shopify/slate-analytics/index.js

The function now looks like this

function event(name, payload = {}) { return null; const config = rc.get();

if (!config.tracking) { return Promise.resolve(); } ...