Open erulabs opened 3 years ago
Thanks for the PR, lint fails though (as seen at the failing CI) with
/home/travis/build/Sorunome/mx-puppet-bridge/src/store.ts:205:4 ERROR: 205:4 await-promise Invalid 'await' of a non-Promise value.
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
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 await
for Connect, my Node instance silently exits with status code 0. Can you confirm that your code - when merged with upstream - actually produces correct / expected behaviour? If so, that would indicate that it's actually my environment and I can work to simplify it further.
@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 rr
) gave me nothing at the point of failure. After 2 days at it, I ended up deciding to abandon my codebase rather than investigate it any further, and planned to rewrite it in Rust to avoid Node in the future.
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
getSchemaVersion
fails, 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!