ECONNRESET in Azure Postgres

[apitzele]

I am using the new managed Postgres service in Azure. My application doesn't have a problem connecting to actual PostgreSQL databases. However, a migrate up against the managed database consistently results in a fatal exception that occur after the migration completes.

Since the migrations run successfully, the problem seems to be related to how the connection is getting terminated.

Error: read ECONNRESET
    at exports._errnoException (util.js:1050:11)
    at TLSWrap.onread (net.js:581:26)

The application uses the latest version of db-migrate for node and the most recent pg driver.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[wzrdtales]

Hey @apitzele,

unfortunately we can't help you if you don't provide us all informations necessary to reproduce your case.

This means, always post:

• used node version
• used npm version
• used db-migrate version
• used driver and its version
• used plugins
• full output of the verbose run
• in complex cases a full gist, as an executable proof
• if necessary used migrations and configuration details (replace sensible informations before posting configs!)
• if necessary code samples

As soon as you provide us all information needed, we have an easy way to reproduce your problem and provide you with the help or bugfix you need.

Thank you.

[apitzele]

Hello @wzrdtales,

This is our enviroment:
node version: reproduced in 6.1.1 (latest stable) and 7.9.0
npm version: 4.2.0
db-migrate version: 0.10.0-beta.21
db-migrate-pg version: 0.2.4
os : reproduced on both CentOS and Windows

I reproduced the issue in a bare server.js (below) with only the db-migrate dependencies included (see package.json also below)

This is the full output:

PS C:\Dev\tmp\pg> node server.js
[INFO] No migrations to run
[INFO] Done
MIGRATION COMPLETED
[ERROR] Error: read ECONNRESET
    at exports._errnoException (util.js:1050:11)
    at TLSWrap.onread (net.js:581:26)
PS C:\Dev\tmp\pg>

server.js

'use strict';

require('db-migrate-shared').log.setLogLevel(5);

const { getInstance } = require('db-migrate');
const parseDbUrl = require('parse-database-url');

function migrateDb ({ databaseUrl, databaseSchema = 'public' }) {
    const custom = parseDbUrl(databaseUrl);
    custom.schema = databaseSchema;
    const dbmigrate = getInstance(true, {
        cwd: __dirname,
        config: { custom },
        env: 'custom' }
    );
// NOTE: dbmigrate.up returns a resolved promise.  The exception gets raised after the last script completes 
    return dbmigrate.up();    
}

const url = 'postgres://azureconnectionstring';       
migrateDb({ databaseUrl: url })
  .then(() => {console.log('MIGRATION COMPLETED')});

package.json

{
  "name": "azuredisconnect",
  "dependencies": {
    "db-migrate": "^0.10.0-beta.21",
    "db-migrate-pg": "^0.2.4"
  }
}

[wzrdtales]

Hey @apitzele,

unfortunately, this is still missing the verbose run. As I wont pay any money on Azure, I will not be able to reproduce this, so I will need your help to provide me with all the stack traces.

Your examples look fine, also I don't know why your setup was build so complicated, while everything in this would be completely equal to passing no custom config at all and just setting the DATABASE_URL environment variable. Did you removed parts from here or why is this?

Can you execute just a pure db-migrate up command on that azure service?

[wzrdtales]

The only thing that I can see is, that it seems to eliminate the connection after it is done with everything. So somewhere in the closing routine. Does it execute any mirgrations though?

[apitzele]

When there are migrations to run, they will all complete successfully. However, it will always fatal sometime afterwards. Since it's an ECONNREST, I'm assuming the crash occurs during disconnect.

Also, I keep the log level set to 5 which should emit debug/verbose level logs.

require('db-migrate-shared').log.setLogLevel(5);

Is there another flag I should be setting? Would you like to see Node's logs?

[apitzele]

In regards, to your question above, your assumption was correct. The example I posted with the custom config was just extracted from the application (so it had a bit more complexity than required for a bare bones demo). However, I can reproduce the issue without a custom config.

[wzrdtales]

Actually the log level setting for this intend is kind of wrong. But good thing that you outline this, as we can make this easier for users and add this to the API directly though.

Loglevel is set binary, 5 would mean just info and error, 15 would catch all levels while verbose can only be triggered if you have the global verbose flag set to true (now that I realize this, this is pretty unconsistent should refactor this piece of code also at some point). The latter one would be the one you need to set though.

I would really need to know the verbose level logs though. Everything I know is that it seems to fail after the migrations have been done. I can just assume as the error from your error above, that this is happening while actually closing the connection just as you also assume, as the error is on Core Level. This could be due to a non standard behavior and I wouldn't be surprised to see any, I mean we talk about microsoft, that would'nt be the first time though. If this is really the case, no one can actually help you but them.

So to figure this out, do the following steps:

• Enable the global.verbose flag after you've created the db-migrate instance with getInstance
• test everything post verbose output

Repeat this, but this time use the native pg driver, for this you need to specify in your config native: true and install the the native driver pg-native accordingly.

[wzrdtales]

To add actually for setLogLevel numbers do not work at all. You can pass either a string like sql|error|... or an object

{
   "sql": true,
   "info": true
}