2.6.5 not sending pushes, went back to 2.4.2, pushes are ok

[dongalor]

Issue Description

Updated to 2.6.5, pushes not working, i'm having problems with pushes:

Went back to 2.4.2:

npm install parse-server@2.4.2 --save

everything is working well

I've seen #4256, and I've seen this comment, which might be related to my problems:

hey @flovilmart are you saying this will be updated in 2.6.4?
@jeffreyjackson yes!

Expected Results

I'd like to have most recent version, cause I feel like lack of performance issues updates in last versions.

Environment Setup

• Server
  • parse-server version: 2.6.5
  • Operating System: ubuntu16.04-x86_64

Logs/Trace

0|parse-wr | verbose: _PushStatus n59yItvDR0: sending push to 1 installations
0|parse-wr | verbose: Sending push to 1
0|parse-wr | verbose: _PushStatus n59yItvDR0: sent push! 0 success, 1 failures
0|parse-wr | verbose: _PushStatus n59yItvDR0: needs cleanup devicesToRemove=[]

[flovilmart]

Can you provide your push configuration please?

[brianyyz]

Over on SO there is lots of chatter about APNS arbitrarily throttling delivery of data pushes and a new process DuetActivitySchedulerDaemon that can intercept a push notification that has been successfully delivered to your device and prevent it from being delivered to your appDelegate based on things like frequency of the silent notifications and battery state.

I spent two days trying to figure out why my server's silent push notifications would mysteriously stop being received by my test devices until I restarted them. I haven't 100% verified that this is the cause but if you are using silent notifications to trigger activity you need to handle the use case that they could be throttled by APNS or blocked at the device which means your appDelegate may never see them.

[flovilmart]

What's bugging me is that the push adapter is not reporting/logging the error when sending the push. As you're running with VERBOSE=1, and the failure was related to APNS not being able to transmit, it should be logged. There isn't any other logs related to the parse-server-push-adapter? Can you try the same running the sever locally and targeting the push with your test device? (also, provide your push configuration please).

[dongalor]

I'm running with VERBOSE=1

My push configuration is:

push: {
ios: {
pfx: "/path/to/certs/file.p12",
passphrase: "",
bundleId: "com.company.AppName",
production: true
}
},

I'll try running it locally, and report my results. Thank you in advance!

[brianyyz]

Small point not directly related bundleId is deprecated and replaced with topic.

[dongalor]

brianyyz, thanks for reply, yeah, I have had deprecation warning, but I already tried using topic instead of bundleId, same story...

[flovilmart]

@dongalor do you have some more logs for us?

[brianyyz]

@dongalor would you be able to share the code that is creating the push payload as well ?

[dongalor]

Here's my code, which I use to test my pushes:
https://gist.github.com/dongalor/96d13ee1b0344d222f4a4caf899bd8ed

this exact code is working well on parse-server@2.4.2

[flovilmart]

If you run the query on itself does it work? ie: does it return installations?

[paulovitin]

I have the same problem here @dongalor. What is the database you are using?

My problem is because Im using Postgres. The 2.6.5 version support "expiration_interval" now. When we update the version, the column in _PushStatus is missing then, the push notification stops. I added the column manually and works now.

When schema change, we need a better option to solve problems like this.

The log trace:

2017-11-10T18:53:32.413657765Z �[31merror�[39m: _PushStatus undefined: error while sending push error: column "expiration_interval" of relation "_PushStatus" does not exist
2017-11-10T18:53:32.413692926Z     at Connection.parseE (/parse-server/node_modules/pg/lib/connection.js:546:11)
2017-11-10T18:53:32.413700050Z     at Connection.parseMessage (/parse-server/node_modules/pg/lib/connection.js:371:19)
2017-11-10T18:53:32.413705701Z     at TLSSocket.<anonymous> (/parse-server/node_modules/pg/lib/connection.js:114:22)
2017-11-10T18:53:32.413711165Z     at emitOne (events.js:96:13)
2017-11-10T18:53:32.413715592Z     at TLSSocket.emit (events.js:188:7)
2017-11-10T18:53:32.413720755Z     at readableAddChunk (_stream_readable.js:176:18)
2017-11-10T18:53:32.413725436Z     at TLSSocket.Readable.push (_stream_readable.js:134:10)
2017-11-10T18:53:32.413733407Z     at TLSWrap.onread (net.js:547:20)

[montymxb]

@paulovitin If that's the case using 2.6.3 would work, as the expiration_interval was introduced in 2.6.5 (2.6.4 has a CLI bug in it but you could use that too). I would think that the schema would have been auto-updated on start though.

[paulovitin]

@montymxb we have a docker auto-redeploy, and the auto-updated for schema doesnt happened.

[montymxb]

I'll take a look and see if I can replicate this upgrade issue regarding expiration_interval.

[montymxb]

@paulovitin I can confirm that there is a Schema upgrade issue, but only in postgres. Mongodb looks to handle it properly. I'm going to open up a separate issue with further details on that specifically, including reproducability.

@dongalor if you're using postgres as your database it's possible that you're experiencing the same issue post-upgrade.

::EDIT:: Postgres upgrade issue opened under #4338