Node Express 500 Error: Unknown encoding - javascript

I am running an Express application on Nodejitsu. It's Node 0.8 and Express 3.4.0. The application works absolutely fine locally, but one of the routes has stopped working and returns the following error when I push to Nodejitsu:
Express
500 Error: Unknown encoding
at Buffer.toString (buffer.js:440:13)
at Object.fs.readFileSync (fs.js:241:33)
at handleCache (/opt/run/snapshot/package/node_modules/ejs/lib/ejs.js:65:21)
at exports.renderFile (/opt/run/snapshot/package/node_modules/ejs/lib/ejs.js:206:14)
at View.exports.__express [as engine] (/opt/run/snapshot/package/node_modules/ejs/lib/ejs.js:510:22)
at View.render (/opt/run/snapshot/package/node_modules/express/lib/view.js:76:8)
at Function.app.render (/opt/run/snapshot/package/node_modules/express/lib/application.js:504:10)
at ServerResponse.res.render (/opt/run/snapshot/package/node_modules/express/lib/response.js:798:7)
at exports.m2 (/opt/run/snapshot/package/routes/login.js:27:9)
at callbacks (/opt/run/snapshot/package/node_modules/express/lib/router/index.js:164:37)
I have nt changed anything about the route. I added a new route to the sme routing file which works, but should not affect this route). I haven't changes the view template in any way, or done anything I can think of to change the encoding. Given that Nodejitsu just takes my package.json and installs all the same modules, everything about the app should be identical.
I'm not sure how to track down the issue since the Nodejitsu logs are identical to the output error and I can't reproduce locally. I tried commenting out the new route, and it had no effect.

Related

TypeError when testing with Jest and Formidable

I have wrote a cusom express middleware to pars an incoming multipart form.
The middleware works fine when launched in local or deployed but the test with jest fails with the error
TypeError: Cannot set property domain of [object process] which has only a getter
The issues seems to come from the package asap used by formidable.
I think that Jest is putting some limitations on the process object since the line where everything breaks is
domain.active = process.domain = null;
in the file raw.js
Does anyone has any workaround or solution for this issue? I cannot migrate to formidable V3 at the moment so that's not an option

Getting EISDIR error from NodeJS when attempting to start app via Expo (React Native)

I'm getting the old 'directory is not a file' error with Node, and the output does not make it clear what exactly it's trying to parse. I've tried putting logging in and everything to find the issue, and even created a brand new project but the issue persists. Can anyone shed any light on this?
Error: EISDIR: illegal operation on a directory, read
at Object.readSync (fs.js:592:3)
at tryReadSync (fs.js:366:20)
at Object.readFileSync (fs.js:403:19)
at UnableToResolveError.buildCodeFrameMessage (C:\Users\thepo\Applications\WakeMyPC\node_modules\metro\src\node-haste\DependencyGraph\ModuleResolution.js:304:17)
at new UnableToResolveError (C:\Users\thepo\Applications\WakeMyPC\node_modules\metro\src\node-haste\DependencyGraph\ModuleResolution.js:290:35)
at ModuleResolver.resolveDependency (C:\Users\thepo\Applications\WakeMyPC\node_modules\metro\src\node-haste\DependencyGraph\ModuleResolution.js:168:15)
at DependencyGraph.resolveDependency (C:\Users\thepo\Applications\WakeMyPC\node_modules\metro\src\node-haste\DependencyGraph.js:353:43)
at C:\Users\thepo\Applications\WakeMyPC\node_modules\metro\src\lib\transformHelpers.js:271:42
at C:\Users\thepo\Applications\WakeMyPC\node_modules\metro\src\Server.js:1098:37
at Generator.next (<anonymous>)
The problem turned out to be that some of the versions of modules that I installed using npm were not compatible with expo. These were indicated earlier than the error in the output for the 'expo start' command. Because these were info logs, I didn't pay enough attention to them. However, after several hours I decided to fix them and it fixed my problem.
The fix was to follow each individual package named in the output and run 'expo install '.
Make sure the entryPoint key in your app.config.js or app.json file is correctly set.
I had an intermittent error very similar to this and it was related to a bug with remote debugging.
Turning off "Debug Remote JS" in the Expo Go app shake-to-show developer menu avoided this issue for me (logs and errors still show in the Metro console).
Here's the exact error message I was getting (and sometimes the app would just fail silently without any error). It's almost identical to the error in the question with a few different line numbers (maybe from different versions).
Error: EISDIR: illegal operation on a directory, read
at Object.readSync (node:fs:721:3)
at tryReadSync (node:fs:431:20)
at Object.readFileSync (node:fs:477:19)
at UnableToResolveError.buildCodeFrameMessage
As for "why", there's some related discussion on this expo forum thread which in turn links to this React Native bug (claimed to be fixed in Expo CLI 4.13.1 but many users reporting similar issues in recent versions).
It might be related to the reported issues with Reanimated 2 and Expo's remote debugging (see this reanimated issue and the warning note in Expo's documentation) for Reanimated.

Receiving an Internal Server Error when initializing Next js App

I wanted to start getting into Next js, and I followed the tutorial on their site (Next js Tutorial) to a t - with no luck. I run npm run dev and I receive the following messages on my console, and terminal respectively:
Failed to load resource: the server responded with a status of 500 (Internal Server Error)
and Error: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
You might have mismatching versions of React and the renderer (such as React DOM)
You might be breaking the Rules of Hooks
You might have more than one copy of React in the same app
I am running Node v.13.13.0, React version 16.13.1 and React-DOM version 16.13.1.
I've tried creating my own app from scratch using npx-create-next-app, and I get the exact same error.
I just want to get a Next js app up and running, any help is greatly appreciated.
I had the same problem but I was able to resolve it in the end. I was using GitBash as my command window which was causing the internal server error. Once I switched to windows cmd, everything worked fine.

node js web app on AWS failed to lookup failed to lookup view "pages/home" in views directory "/var/app/views"

I'm trying to put my simple node js web app on AWS EB but it seems like it has a problem with path. I'm running windows on my machine and it works but when I deploy it on EB it gives me the following error
Error: Failed to lookup view "pages/home" in views directory "/var/app/views"
at EventEmitter.render (/var/app/current/node_modules/express/lib/application.js:579:17)
at ServerResponse.render (/var/app/current/node_modules/express/lib/response.js:961:7)
at null.<anonymous> (/var/app/current/controller/app.js:113:14)
at tryCatcher (/var/app/current/node_modules/bluebird/js/release/util.js:16:23)
at Promise.successAdapter [as _fulfillmentHandler0] (/var/app/current/node_modules/bluebird/js/release/nodeify.js:23:30)
at Promise._settlePromise (/var/app/current/node_modules/bluebird/js/release/promise.js:557:21)
at Promise._settlePromise0 (/var/app/current/node_modules/bluebird/js/release/promise.js:605:10)
at Promise._settlePromises (/var/app/current/node_modules/bluebird/js/release/promise.js:684:18)
at Async._drainQueue (/var/app/current/node_modules/bluebird/js/release/async.js:126:16)
at Async._drainQueues (/var/app/current/node_modules/bluebird/js/release/async.js:136:10)
at Immediate.Async.drainQueues [as _onImmediate] (/var/app/current/node_modules/bluebird/js/release/async.js:16:14)
at processImmediate [as _immediateCallback] (timers.js:383:17)
my code for path
var path = require('path');
var app = express();
app.use(express.static(path.resolve('../public')));
app.set('views',path.resolve('../views'));
app.set('view engine', 'ejs');
I'm assuming you're using the path module to resolve directory and file names (to avoid issues with the differences between Windows and linux filesystems).
It could be a file permissions or ownership issue. Check that the user under which the node process is running has read permissions on the relevant directories and files.
It could also be a path resolution issue. It looks like your app is in /var/app/current/, but you're trying to find files in /var/app/views/. Should work if that's how your app is structured, but it would be problematic if you intended to look for files in /var/app/current/views/.
I had similar issue, my problem is that I forget to zip the view sub directory in my root directory recursively, thus resulting in a empty view directory when deploy to AWS Elastic Beanstalk. So when packing your code you should use something like zip -r example.zip . .
Just concentrate on case sensitivity. Ensure that the filename passed on the render is exactly the same as the file on the server ...
eg.
res.render("Challenge",... having a view filename challenge.hbs... WILL FAIL
res.render("challenge",... having a view filename challenge.hbs... WILL PASS

Meteor crashing while building

I am building a fairly rather simple Meteor project on Windows 8, and despite both re-installing meteor, and manually re-setting the library, after the app has run for a short time meteor crashes and will not restart. Meteor is also unable to run reset, and I haven't been able to identify exactly what it is that causes this arise in the first place. There is a consistent error I get from the ccorcos:swipe, but runtime errors should not be crashing meteor right?
I have tried changing/removing the files in .meteor/client.
My question is both to identify what could be causing this particular error (what does "stat" mean in this context? other error messages I have found have while searching have been far more useful) as well as generally if there is a faster way of hard resetting a meteor project than running meteor create proj_name in a new folder and manually moving over the source files.
The stacktrace is below.
The packages I use are
meteor-platform
insecure
bevanhunt:leaflet
mdg:geolocation
accounts-facebook
service-configuration
less stevezhu:lodash
ccorcos:swipe
iron:router
underscore
coffeescript
accounts-ui
accounts-password
C:\Users\Fjafjan\Documents\GitHub\progress>meteor run
[[[[[ C:\Users\Fjafjan\Documents\GitHub\progress ]]]]]
=> Started proxy.
=> Started MongoDB.
C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\dev_bundle\lib\node_modules\fibers\future.js:245
throw(ex);
^
Error: EPERM, stat 'C:\Users\Fjafjan\Documents\GitHub\progress\.meteor\local\build\programs\web.browser\packages'
at Object.Future.wait (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\dev_bundle\lib\node_modules\
fibers\future.js:398:15)
at Object.wrapper [as stat] (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\files.js:1350:24
)
at C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\files.js:454:43
at Array.forEach (native)
at Function._.each._.forEach (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\dev_bundle\lib\node_m
odules\underscore\underscore.js:79:11)
at Object.files.cp_r (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\files.js:444:5)
at C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\files.js:456:13
at Array.forEach (native)
at Function._.each._.forEach (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\dev_bundle\lib\node_m
odules\underscore\underscore.js:79:11)
at Object.files.cp_r (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\files.js:444:5)
at C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\files.js:456:13
at Array.forEach (native)
at Function._.each._.forEach (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\dev_bundle\lib\node_m
odules\underscore\underscore.js:79:11)
at Object.files.cp_r (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\files.js:444:5)
at Object.files.rename (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\files.js:1401:13)
at Object.files.renameDirAlmostAtomically (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\fi
les.js:810:11)
at [object Object]._.extend.complete (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\builder
.js:482:11)
at C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\bundler.js:1933:13
at C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\bundler.js:2147:20
at C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\buildmessage.js:264:13
at [object Object]._.extend.withValue (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\fiber-
helpers.js:115:14)
at C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\buildmessage.js:257:29
at [object Object]._.extend.withValue (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\fiber-
helpers.js:115:14)
at C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\buildmessage.js:255:18
at [object Object]._.extend.withValue (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\fiber-
helpers.js:115:14)
at C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\buildmessage.js:246:23
at [object Object]._.extend.withValue (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\fiber-
helpers.js:115:14)
at Object.capture (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\buildmessage.js:245:19)
at Object.exports.bundle (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\bundler.js:2040:31)
at C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\run-app.js:554:24
at time (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\profile.js:231:28)
at Function.run (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\profile.js:377:12)
at bundleApp (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\run-app.js:544:34)
at [object Object]._.extend._runOnce (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\run-app
.js:591:35)
at [object Object]._.extend._fiber (C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\run-app.j
s:821:28)
at C:\Users\Fjafjan\AppData\Local\.meteor\packages\meteor-tool\1.1.3\mt-os.windows.x86_32\tools\run-app.js:402:12
As I'm new to programming, I can't tell you why this happens, but I was having the exact same problem. If you install a package using meteor add (package) while you have your app open in a code editor, it causes the app to break. Try closing the editor and refreshing everything. It worked for me.
Kill the meteor processes and reset the project.
ps aux | grep meteor
kill -1 [PID_OF_METEOR_PROC]
cd /path/to/project/
meteor reset
Replace [PID_OF_METEOR_PROC] with the actual PID or run once for each PID, and use the correct path to your meteor project

Categories