wait for postgres, possibly fixes https://github.com/matrix-discord/mx-puppet-discord/issues/78 #64
Conversation
erulabs
changed the title
|
Thanks for the PR, lint fails though (as seen at the failing CI) with
|
Thanks @Dessix ! Co-authored-by: Zoey <[email protected]>
|
sqlite doesn't return a promise for db.Open() so I went ahead and added a Promise.resolve() around db.Open in store such that it is always a promise, even if it isn't. Should fix the typescript lint (and probably also fix sqlite) I've only tested this with postgres as in my setup we're always using psql, and never using sqlite. That said, I can confirm this does resolve a number of the schema issues! |
|
The multi-layer promise unpacking is so unintuitive, but ... Yeah, that hack should work. |
|
The CI says the unit tests are failing |
| // Hide username:password | ||
| const logConnString = this.connectionString.substr( | ||
| this.connectionString.indexOf("@") || 0, | ||
| ); | ||
| log.info(`Opening ${logConnString}`); | ||
| this.db = pgp(this.connectionString); | ||
| // Wait for postgres to be ready by returning a promise for a connection | ||
| return this.db.connect(); |
There was a problem hiding this comment.
Changing this return to await fixes the compilation error:
| return this.db.connect(); | |
| await this.db.connect(); |
|
If you'd like, I've rebased this changeset to the latest upstream HEAD, applied the compilation fix I commented above, and pushed it to Dessix/mx-puppet-bridge/postgres-wait. |
|
@erulabs I received a message notification from you on a commit but it doesn't appear to have made it into this PR? Additionally, my branch doesn't appear to actually succeed- I think it may be a problem with my build or test environments, but once I get to the |
|
@Dessix what's the status on your side? Since it does sound like a good feature. |
|
@dsonck92 I had a repro but I couldn't figure out what was leading to Node exiting. Strace and node-debug (and even |
Hello!
This PR ensures that we always wait for postgres to be connected before we continue on in the code - this prevents a problem where
getSchemaVersionfails, and then returns 0 as the schema version, which causes some thrashing of the database :( - this ensures we never run getSchemaVersion() until we know that query will fail for non-connection reasons. Rebooting a machine is a good example where postgres and the bridge will both start at the same time, which can lead to this issue.I'm still testing to ensure that this 100% resolves https://github.com/matrix-discord/mx-puppet-discord/issues/78 (I think it will), but at any rate it's probably a good idea to ensure PG is ready before running :)
Thanks!